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Abstract 

We  introduce  a  new  region-based  memory  management  technique  that  allows  flexible  memory  usage 
patterns  and  is  provably  safe.  Our  technique  is  explicit  and  manual  like  C’s  malloc  and  free,  and  it 
allows  programmers  to  exert  a  similar  degree  of  control  over  the  program  behavior.  Our  method  is  quite 
simple  in  spite  of  this  expressiveness  and  safety. 

We  apply  the  technique  to  a  small  functional  language  to  formally  describe  the  core  concepts,  prove 
its  safety,  and  argue  its  usability  and  efficiency  analytically.  In  particular,  we  show  that  the  system  can 
efficiently  encode  more  rigid,  traditional  regions  whose  lifetime  is  bounded  by  that  of  a  stack  frame.  We 
also  show  that  the  technique  works  nicely  with  multi-threaded  and  imperative  programs. 


1  Introduction 

In  software  practice,  there  are  two  widely-used  heap  memory  management  approaches:  explicit  management 
via  malloc  and  free  or  implicit  management  via  garbage  collection.  Both  approaches  have  well-known 
disadvantages.  The  problem  with  malloc  and  free  is  that  verifying  memory  safety  is  difficult.  Garbage 
collection  overcomes  this  problem  at  the  cost  of  making  it  difficult  to  control  when  objects  are  deallocated, 
which  makes  garbage  collection  unattractive  in  situations  that  require  tight  space  or  timing  guarantee. 
In  addition,  experienced  programmers  can  often  produce  more  efficient  code  given  the  ability  to  do  manual 
memory  management.  Thus  a  memory  management  system  that  allows  programmers  to  exert  manual  control 
and  yet  be  provably  safe  is  of  practical  interest. 

Recently,  there  have  been  a  number  of  proposals  [4,  18,  9,  2,  11]  based  on  the  concept  of  regions  [14,  15], 
that  allow  safe,  explicitly  controlled  memory  management.  All  these  systems  (with  the  exception  of  portions 
of  [11]  which  was  developed  independently  from  our  work  around  the  same  time)  guarantee  safety  at  compile 
time. 

This  paper  presents  a  new  mostly-static,  memory-safe  region  system.  It  is  not  totally  static  in  the  same 
sense  as  the  systems  listed  above  because  the  deletion  of  a  region  could  fail  and  result  in  a  run-time  error, 
and  the  programmer  is  required  to  add  run-time  checks  to  see  if  regions  are  alive  at  strategic  points  in  the 
program.  The  system  is  mostly  static  because  it  guarantees  at  compile  time  that  no  other  run-time  checks 
are  necessary  for  the  program  to  be  memory  safety.  Also,  unlike  dangling  pointer  dereferences,  our  run-time 
errors  are  well-behaved  and  the  program  can  recover  by,  for  example,  catching  the  thrown  exception  ala  ML 
and  Java. 

*This  research  was  supported  in  part  by  Subcontract  no.  PY-1099  to  Stanford,  Dept,  of  the  Air  Force  prime  contract  no. 
F33615-00-C-1693. 
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U,  V,  W,  X,  Y,  Z  e  RegVars  U  {Xsr}  u,  v,  w,  x,  y,  z  £  Vars  U  {sr}  L  RegVars  U  {Xsr}  r,  s,  t  £  Regions 

types  r  ::=  (VX.ri  — ^  T2)@Y  |  r@X  |  reg(X)@Y  |  3X.r 

expressions  e  ::=  x  |  let  x  =  ei  in  62  |  AXAxir.ei  at  62  |  ei[X]  62  |  e  at  e  |  e.i  |  pack  e  as  3X.r  |  open  x  =  ei  as  r  in  62 
newregion  at  e |  freeregion  e  |  useregion  ei  in  62 

Figure  1:  Small  region  language:  source  syntax 


Compared  to  a  totally-static  approach,  our  system  has  a  slightly  weaker  memory-safety  guaranteed  But 
we  believe  that  there  are  enough  benefits  with  our  mostly-static  approach  to  justify  the  trade-off.  One 
drawback  of  a  totally  static  approach  is  that  it  often  trades  simplicity  and  ease-of-use  for  expressiveness 
because  a  simple  static  system  often  limits  the  kind  of  programs  that  can  be  proven  safe.  In  contrast,  our 
system  allows  a  high  degree  of  expressiveness  without  complicating  the  static  system.  In  particular,  a  region’s 
lifetime  is  not  tied  to  a  stack  frame,  and  instead  regions  may  be  created  and  deleted  at  any  program  point. 
We  also  argue  in  Section  4.2  that  a  run-time  error  is  likely  to  indicate  a  bug  in  the  programmer’s  thinking 
rather  than  a  limitation  of  the  system. 

Our  technique  is  best  understood  by  conceptually  dividing  it  into  a  static  part  and  a  dynamic  part.  The 
static  part  is  simple,  based  on  a  type  system  resembling  [15].  The  dynamic  part  is  simple  for  the  most 
basic  implementation,  which  we  shall  stick  with  until  Section  3.  The  run-time  behavior  is  transparent  to 
the  programmer.  That  is,  the  programmer  can  easily  tell  from  the  source  code  when  each  dynamic  check 
occurs,  which  is  important  for  control. 

We  now  describe  the  core  concepts  of  our  technique,  which  we  call  use  counting.  (We  shall  slightly  modify 
these  concepts  in  Section  3  to  enable  further  flexibility).  The  run-time  system  maintains  two  data  values 
per  region: 

•  Validity  bit:  indicating  whether  region  has  been  deleted  (=  0)  or  not  (=  1). 

•  Use  counter,  a  non-negative  integer  which  starts  from  0  and  is  incremented  and  decremented  explicitly 
by  the  program. 

Via  a  combination  of  static  and  dynamic  checks,  we  enforce  the  following: 

(1)  When  accessing  a  memory  location,  the  use  counter  of  the  region  containing  the  memory  location  is 
greater  than  0. 

(2)  When  deleting  a  region,  the  region’s  use  counter  is  0. 

(3)  When  incrementing  the  use  counter  of  a  region,  the  region’s  validity  bit  is  1. 

It  is  not  hard  to  see  that  these  conditions  are  sufficient  for  memory  safety:  dangling  references  are  never 
accessed.  We  check  the  condition  (1)  statically  and  check  (2)  and  (3)  dynamically.  Since  deletions  are 
explicit,  dynamic  checks  for  (2)  are  transparent.  Incrementing  a  use  counter  is  also  explicit,  so  dynamic 
checks  for  (3)  are  also  transparent. 

The  trick,  then,  is  to  make  the  static  check  for  (1)  simple.  To  this  end,  we  design  the  language  so  that 
programs  adhere  to  a  certain  syntactic  pattern  when  incrementing  and  decrementing  use  counters.  Consider 
the  following  pseudo-code.  Suppose  r  denotes  some  region. 

incrementjic (r) 

. . .  use  r  . . . 
decrementjic (r) 


^Though  in  principle,  any  well-behaved  run-time  error  is  a  part  of  the  program  semantics,  and  therefore  we  could  argue  that 
our  system  is  just  as  static. 
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values  V 

expressions  e 


pack  u  as  •  I  A»Ax;».e  at  r  |  -y  at  r  |  reg  r  at  s  |  abort 

X  I  let  X  =  ei  in  62  I  A»Ax:».ei  at  62  |  ei[»]  62  |  e  at  e  |  e.i  |  pack  e  as  •  j  open  x  =  ei  as  •  in  62 
newregion  at  e  |  freeregion  e  |  useregion  ei  in  62  |  w  |  inuse  (reg  r  at  s)  in  e 


contexts  E  ::=  [  ]  |  let  x  =  in  e  |  A»Ax:».e  at  E  \  _E[»]  e  |  «[•]  E  \ 

{v,E,e)ate\va.tE\  pack  E  as  •  \  open  x  =  as  •  in  e  | 

newregion  at  E  \  freeregion  E  \  useregion  in  e  |  inuse  (reg  r  at  s)  in  E 


Figure  2:  Small  region  language:  type-erased  intermediate  expressions  and  evaluation  contexts 


The  operations  increment_uc  (r)  and  decrementjic  (r)  respectively  increment  and  decrement  the  use 
counter  of  r.  Our  proposal  is  to  force  programs  to  adhere  to  this  block  pattern  when  manipulating  a 
use  counter.  To  this  end,  instead  of  increment_uc  (r)  and  decrementjic  (r) ,  we  introduce  a  single  language 
construct  for  increment  and  decrement: 

useregion  ei  in  62 

which  evaluates  ei  to  a  use  counter,  increments  it,  executes  62,  then  decrements  the  use  counter  after  62 
finishes.  From  a  programmer’s  point  of  view,  useregion  enables  access  to  the  region  within  the  lexical  scope. 
The  resulting  system  is  simple  and  easy  to  use,  like  stack-of-regions  systems  [9,  2],  but  enjoys  expressiveness 
comparable  to  more  complex  approaches. 

1.1  Contributions  and  Overview 

The  main  technical  contributions  of  the  paper  are: 

•  a  formal  presentation  of  the  basic  use-counting  system  and  the  proof  of  safety  (Section  2). 

•  an  improvement  to  the  base  system:  “use  counters  for  free”  (Section  3) .  This  feature  is  not  introduced 
immediately  in  the  paper  since  it  is  more  natural  to  understand  it  as  a  modification  to  the  base  system. 

•  an  analytical  evaluation  of  the  system,  including  efficient  encoding  of  stack-of-regions  style  memory 
management  and  multi-threaded  programming  (Sections  4  and  5). 

In  addition  to  the  above,  we  provide  small  but  illustrative  examples  throughout  the  paper.  Section  6  discusses 
our  own  experience  with  a  toy  implementation.  Section  7  discusses  related  work,  and  Section  8  concludes. 


2  Regions  for  a  Small  Language 

We  first  apply  use  counting  to  a  call-by- value  monomorphic  lambda  calculus  with  tuples  shown  in  Figure  1. 
This  small  region  language  is  designed  to  illustrate  the  new  technique  in  a  self-contained  manner  and  there¬ 
fore  omits  features  such  as  parametric  polymorphism  over  types  and  effect  sets,  recursive  types,  non-heap 
allocated  tuples,  and  mutable  values.  But  these  features  can  be  incorporated  with  little  additional  effort  by 
leveraging  off  previous  research  on  region-based  memory  management  (see,  e.g.,  [8]  for  an  extensive  study 
incorporating  these  features  and  more  in  a  stack-of-regions  style  framework) .  Appendix  A  shows  the  system 
extended  with  some  of  these  features. 

RegVars  is  an  infinite  set  of  region  variables.  Each  region  variable  refers  to  some  region.  For  example, 
a  function  closure  allocated  in  the  region  referred  to  by  Y  has  a  type  of  the  form  (VX.ri  — ^  T2)@Y  with  ti 
as  the  argument  type  and  T2  as  the  return  type.  Note  that  the  function  may  be  polymorphic  in  the  region 
variables  X,  which  are  assumed  to  be  distinct.  (We  use  the  notation  a  to  mean  some  tuple  (01,02,  ...,o„).) 
In  addition,  each  function  type  carries  a  set  of  region  variables,  an  effect  set  L,  referring  to  a  superset  of  the 
regions  the  function  accesses.  Similarly,  a  tuple  of  values  (of  the  types  r)  allocated  in  X  has  the  type  r@X. 
The  type  reg(X)@Y  is  the  type  of  a  region  handle  of  the  region  referred  to  by  X.  A  region  handle  is  a  program 
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i?(r)  =  (l,-) 


i?(s)  =  (l,-) 


R,  _E[A»Ax:».e  at  (reg  r  at  s)]  ^  R,  _E[A»Ax:».e  at  r] 

-  [E] 

R,  i?[open  X  =  (pack  v  as  •)  as  •  in  e]  ^  R,  -B[e[w/x]] 

7?(s)  =  (!,-) 


[FI] 


i?(r)  =  (!,-) 


-R, -E[(A»Ax:».e  at  r)[»]  v]  ^  R,  _E[e[t/x]] 
R{r)  =  {!,-) _ R{s)  =  {!,-) 

R,  R[newregion  at  (reg  r  at  s)] 

^  R  1+)  {t  1-^  (1,0)},  R[pack  (reg  t  at  r)  as  •] 


[F2] 


[Rl] 


R  W  {r  1-^  (— ,  0)},  R[freeregion  (reg  r  at  s)] 

^  R  ttJ  {r  1-^  (0,  0)},  -E[reg  r  at  s] 


[R2] 


R(s)  =  (l,-) 


i  >  0 


R  1+)  {r  1-^  (— ,  i)},  R[freeregion  (reg  r  at  s)] 

^  R  W  {r  1-^  (— ,  i)},  abort 


[R3] 


R(s)  =  (l,-) 


R  W  {r  1-^  (1,  i)},  R[useregion  (reg  r  at  s)  in  e]  ^  R  tt)  {r  (1,  i  +  1)},  R[inuse  (reg  r  at  s)  in  e] 
R{s)  =  {l,-)  R(s)  =  (l,-) 


[R4] 


R  ttJ  {r  (0,  i)},  R[useregion  (reg  r  at  s)  in  62] 

^  R  1+)  {r  I— >  (0,  i)},  abort 


[R5] 


R  1+)  {r  1-^  (6,  i)},  _E[inuse  (reg  r  at  s)  in  v] 

^  R  W  {r  {b,i  —  1)},  E\v\ 


[R6] 


Figure  3:  Small  region  language:  selected  reduction  rules 


value,  so  it  is  allocated  in  a  region  just  like  other  program  values.  Region  handles  are  necessary  because 
the  validity  bit  and  use  counter  for  each  region  must  be  stored  somewhere;  that  is,  each  region  handle  is  a 
pointer  to  a  triple  containing  a  pointer  to  the  head  of  the  region,  a  validity  bit,  and  a  use  counter.^  The 
type  3X.t  is  an  existential  type,  which  is  handy  when  typing  data  structures  containing  region  handles.  (In 
theory,  we  can  always  encode  them  as  higher-order  polymorphic  functions,  but  existential  packages  are  more 
natural.)  We  assume  that  expressions  and  types  are  equivalent  up  to  consistent  renaming  of  bound  variables 
and  bound  region  variables. 

A  program  is  an  expression  whose  only  free  variable  is  sr.  The  set  of  free  variables  for  an  expression  is 
defined  in  the  usual  way.  The  variable  sr  denotes  a  region  handle  of  a  special  region,  rsr-  (It  doesn’t  matter 
which  region  we  pick  to  be  special;  we  just  need  to  pick  one  from  Regions,  an  infinite  set  of  regions,  before 
the  program  starts.)  The  region  rsr  is  special  because  it  is  the  only  region  that  exists  prior  to  the  execution 
of  the  program;  all  other  regions  are  created  by  the  program.  To  see  why  we  need  this  starting  region,  recall 
that  each  region  handle  must  itself  be  allocated  somewhere.  The  core  concepts  described  in  Section  1  implies 
that  in  order  for  a  region  to  be  deleted,  its  region  handle  cannot  be  allocated  within  the  region  itself.  By 
chain  of  reasoning,  there  must  be  at  least  one  pre-existing  region  in  which  the  first  program-created  region 
handle  is  allocated.  We  shall  remove  this  constraint  in  Section  3. 

2.1  Dynamic  Semantics 

The  dynamic  semantics  is  a  series  of  small-step  reductions  from  states  to  states.  A  state  is  a  pair  (R,  e) 
where  e  is  a  program  and  R  is  a  region  map,  which  maps  each  region  r  in  its  domain  to  a  pair  (5,  i)  with 
r’s  validity  bit  b  and  r’s  use  counter  i.  The  starting  state  for  the  program  e  is  ({rsr  (1, 1)})©).  Note 
that  the  starting  region  is  accessible  from  the  start.  In  fact,  the  starting  region  cannot  be  deleted  and  will 
remain  always  accessible,  so  the  program  never  needs  to  manipulate  its  use  counter.  Single  step  reductions 
are  written 

Rl,  Cl  ^  R2,  62 

(We  usually  omit  the  parentheses.)  Type  and  region  variable  information  is  irrelevant  in  reductions,  so  we 
erase  it  from  expressions  by  replacing  each  occurrence  of  a  type  or  a  region  variable  by  •.  The  result  of  this 
erasure  is  an  expression  in  the  language  of  Figure  2. 

^Alternatively,  we  can  implement  a  region  handle  as  a  double- word  value  consisting  of  a  pointer  to  the  head  of  the  region 
and  a  pointer  to  the  pair  containing  the  validity  bit  and  the  use  counter  to  save  dynamic  checks  at  allocation  sites. 
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Figure  3  shows  selected  reduction  rules.  Reductions  may  give  rise  to  expressions  in  the  intermediate 
language  and  use  evaluation  contexts  defined  in  Figure  2.  We  now  discuss  the  reduction  rules.  To  reduce  a 
function  allocation  A*Ax:*.ei  at  62,  first  62  is  reduced  to  a  region  handle  reg  r  at  s.  Then  [FI]  reduces  the 
whole  expression  to  a  function  closure  A*Ax:*.ei  at  r.  The  expression  reg  r  at  s  is  a  region  handle  for  the 
region  r  allocated  in  the  region  s.  Every  region  handle  is  represented  in  this  form.  (So  before  the  program 
starts  reducing,  we  replace  every  occurrence  of  sr  by  reg  rsr  at  rsr-)  In  fact,  every  allocated  program 
value  has  the  form 

a  at  r 

meaning  the  value  denoted  by  a  is  allocated  in  the  region  r.  So,  A*Ax:*.ei  at  r  is  a  function  closure  value 
allocated  in  r.^  The  condition  i?(r)  =  (1,  — )  of  [FI]  says  that  the  region  where  the  function  is  being  allocated 
must  be  alive.  (The  symbol  —  is  a  wild  card.)  In  addition,  the  condition  R{s)  =  (1,  — )  is  required  because 
a  region  handle  also  stores  a  pointer  to  the  head  of  the  region  and  this  needs  to  be  looked  up. 

The  rule  [F2]  is  for  function  application.  It  shows  function  application  as  the  usual  capture-avoiding 
substitution  assuming  r,  the  region  where  the  function  is  allocated,  is  alive. 

The  rule  [E]  is  for  opening  existential  packages  and  is  straightforward. 

Once  e  in  newregion  at  e  is  reduced  to  a  region  handle  reg  r  at  s,  [Rl]  reduces  newregion  at  (reg  r  at  s) 
by  creating  a  new  region  t  and  reducing  to  a  region  handle  of  t  allocated  at  r.  The  binary  operation  i?i  I+IR2 
is  the  union  Ri  U  i?2  if  dom{Ri)  n  dom{R2)  =  0  and  undefined  otherwise.  For  reasons  explained  later,  the 
new  region  handle  is  existentially  packed.  The  conditions  i?(r)  =  (1,—)  and  R{s)  =  (1,—)  are  required 
because  allocating  a  region  handle  is  like  allocating  any  other  program  value,  that  is,  the  region  where  the 
region  handle  is  allocated  must  be  alive  as  well  as  the  region  where  the  region  handle  itself  resides. 

The  rules  [R2]  and  [R3]  handle  freeregion  e.  We  first  reduce  e  to  a  region  handle.  Assuming  that  the 
use  counter  of  the  region  being  deleted  is  0,  [R2]  sets  the  validity  bit  of  the  region  to  0,  indicating  that  the 
region  is  deleted.  Otherwise  the  use  counter  of  the  region  is  greater  than  0,  and  [R3]  reduces  the  whole 
program  to  the  special  value  abort  which  signals  a  failure  of  the  dynamic  check.  Alternatively,  the  language 
could  have  been  designed  so  that  a  dynamic  check  failure  reduces  to  a  special  error  value  or  raises  a  run-time 
exception.  Exactly  what  to  do  when  a  dynamic  check  fails  is  up  to  the  language  designer.  Note  that  both 
[R2]  and  [R3]  require  the  assumption  R{s)  =  (1,  — )  because  the  region  handle  for  r  allocated  at  s  must  be 
looked  up  to  see  which  of  [R2]  or  [R3]  applies. 

The  form  useregion  ei  in  62  increments  and  decrements  use  counters.  First,  ei  is  reduced  to  a  region 
handle  of  some  region  r,  then  if  r’s  validity  bit  is  1,  the  use  counter  is  incremented  and  the  whole  expression 
is  reduced  to  inuse  (reg  r  at  s)  in  62  as  shown  in  [R4].  Otherwise  the  region’s  validity  bit  is  0,  and  [R5] 
aborts  the  program.  Both  [R4]  and  [R5]  require  the  assumption  R{s)  =  (1,—)  because  the  use  counter  and 
the  validity  bit  of  r  are  accessed. 

The  rule  [R6]  reduces  inuse  (reg  r  at  s)  in  e.  First,  e  is  reduced  to  the  value  v,  then  the  use  counter  of 
r  is  decremented  and  v  is  returned,  assuming  that  the  region  where  the  use  counter  is  allocated  is  alive. 

Note  that  the  run-time  system  does  not  physically  check  the  conditions  of  the  form  i?(r)  =  (1,  — ) 
appearing  in  any  of  the  hypotheses  in  Figure  3.  Violation  of  these  conditions  correspond  to  dangling  pointer 
dereferences,  and  we  will  argue  in  Section  2.4  that  well-typed  programs  never  violate  them. 

However,  a  cautious  reader  may  wonder  how  we  can  make  safety  claims  by  assuming  that  the  validity 
bits  even  exist  in  these  hypothesis.  What  if  the  validity  bit  is  deallocated  prior  to  the  reduction?  To  see 
that  such  situation  never  occurs,  observe  that  the  dynamic  semantics  never  deallocates  any  value;  it  just 
sets  some  validity  bits  to  0.  In  order  to  actually  deallocate,  we  first  argue  as  in  the  previous  paragraph  that 
the  conditions  of  the  form  R{r)  —  (1,  — )  are  not  required  if  the  program  is  known  not  to  get  stuck,  which  in 
turn  lets  us  physically  delete  regions  at  [R2]  as  argued  in  Section  2.4. 

3  This  a;  at  r  notation  may  look  strange  to  some  readers.  More  commonly,  when  an  expression  allocates  a  program  value, 
the  expression  reduces  to  a  pointer  pointing  to  the  memory  location  where  the  program  value  is  stored.  But  because  every 
program  value  in  the  language  except  region  handles  is  immutable,  we  save  a  few  characters  by  not  showing  the  extra  level  of 
indirection.  If  some  readers  are  uncomfortable  with  our  notation,  they  may,  for  each  state,  imagine  a  store  partitioned  into 
regions  and  replace  each  a;  at  r  with  a  pointer  to  the  memory  location  containing  a  in  the  r  partition  of  the  store.  Note  that 
region  handles  are  mutable  because  the  validity  bit  and  the  use  counter  may  change.  For  this  reason,  we  have  region  maps  to 
handle  the  extra  level  of  indirection. 
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r(x)  =  r 
A;r  I-  X  :  r;L 


(V) 


A;ri-ei:Ti;L  A;  F  ttJ  {x  ti}  h  62  :  r2;  L 
A;  r  h  let  X  =  ei  in  62  '■  T2\L 


(L) 


A;  r  h  62  :  reg(X)@Z;  L2  fregvarsirr)  U  Li  C  A  tt)  {Y} 
Al+)  {Y};ri±J  {x  1-^  n}  h  61  :  T2-,Li _ X,  Z  £  L2 

A;  r  h  AYAx:ri.6i  at  62  :  (VY.ri  r2)@X;  L2 


A;  r  h  61  :  (Vf.Ti  r2)@Z;  La  {X}  C  A 
A;  r  h  62  :  ri  [X/Y|;  La  Li  [X/Y|  U  {Z}  C  La 


A;r  h  61  [X]  62  :  T2[X/Y];L2 


(F2) 


A;  r  h  6  :  r;  L  A;  F  h  6  :  reg(X)@Y;  L 
A;  F  h  6  at  6  :  r@X;  L 


X,  Y  £  L 


(Tl) 


A;F  h  6  :  {Ti,r2,  ...)@X;  L 

A;  F  h  6i  :  n;  L 


X  £  L 


(T2) 


_ A;F  h  6  :  t;L _ 

A;  F  h  pack  6  as  3X.r  :  3X.r;  L 


(El) 


A;  F  h  61  :  3X.ri;  L  fregvars{Ti)  C  A  tt)  {X} 

A  tt)  {X};  r  tt)  {x  Tl}  h  62  :  T2;  L  fregvars{T2)  C  A 

A;  F  h  open  x  =  61  as  ri  in  62  :  Ta;  L 


(E2) 


A;  F  h  6  :  resi(Y)@Z;  L  Y,  Z  £  L  X/Y 
A;  F  h  newregion  at  6  ;  3X.rep(X)(3)Y;  L 


(Rl) 


A;F  h  6  :  re5(X)@Y;L  Y£L 
A;  F  h  freeregion  6  ;  reg{X)@Y;L 


(R2) 


A;F  h  61  :  reg(X)@Y;L  A;  F  h  62  :  r;  L  U  {X} 
A;  F  h  useregion  61  in  62  :  r;  L 


Y  £  L 


(R3) 


Figure  4:  Small  region  language:  type  checking  rules 


2.2  Static  Checking 

As  stated  in  Section  1,  the  role  of  the  static  checking  is  to  check  that  when  accessing  a  memory  location, 
the  use  counter  of  the  region  in  which  the  memory  location  is  allocated  is  greater  than  0.  The  use  counter  is 
incremented  before  reducing  62  of  useregion  ei  in  62  and  decremented  after  62  reduces  to  a  value.  Therefore 
the  plan  is  to  disallow  accesses  to  a  region  r  except  in  the  context  of  some  useregion  ei  in  62  such  that  Ci 
is  a  region  handle  of  r. 

We  use  a  type  and  effect  system  [7,  12]  where  the  type  judgement  A;  F  h  e  :  t;  L  reads  e  has  the  type  t 
in  the  environment  A;F  and  the  effect  set  L.  In  the  above  judgement,  A,  a  region  variable  environment,  is 
a  set  of  region  variables  and  F,  a  type  environment,  is  a  mapping  from  variables  to  types.  Figure  4  shows 
the  type  checking  rules. 

We  brieffy  discuss  the  type  checking  rules.  In  (V),  note  that  any  L  including  0  can  appear  in  the 
conclusion  because  any  expression  substituted  for  x  must  be  a  value  and  therefore  already  reduced  (because 
of  call- by- value  semantics). 

The  rule  (L)  for  local  variable  definition  is  self-explanatory. 

The  rule  (FI)  types  function  allocation.  The  notation  fregvarsir)  denotes  the  set  of  free  region  variables 
of  r.  The  function  will  be  allocated  in  the  region  specified  by  the  region  handle  62,  referred  to  by  the  region 
variable  X.  The  pointer  to  the  region  is  stored  in  the  region  referred  to  by  Z.  Hence  X,  Z  £  L2  is  required. 
The  assumption  A  l±)  {Y};F  l±)  {x  i-^-  n}  h  ei  :  r2;Li  types  the  body  of  the  function.  Note  that  Li  also 
appears  in  the  function  type;  this  set  is  the  latent  effect  of  the  function  that  takes  place  when  the  function 
is  applied.  Here,  we  have  overloaded  l±l  such  that  Ai  l±)  A2  is  the  standard  disjoint  union. 

The  rule  (F2)  types  function  application.  The  latent  effect  Li  is  carried  in  the  type  of  the  function, 
therefore  Li[X/Y]  C  L2  is  required  because  reducing  the  function  application  leads  to  reducing  the  body  of 
the  function.  Furthermore,  Z  £  L2  is  required  because  the  function  closure  value  is  accessed. 

The  rule  (Tl)  types  tuple  allocation.  The  judgement  A;  F  h  e  :  r;  L  is  a  short-hand  for  A;  F  h  ei  :  ti;  L, 
. . . ,  A;  F  h  e„  :  r„;  L.  Like  in  (FI),  X,  Y  £  L  is  required.  The  rule  (T2)  types  tuple  projection.  The  condition 
X  £  L  is  required  because  the  tuple  is  accessed. 

The  rules  (El)  and  (E2)  type  existential  packaging  and  opening.  Instead  of  explicit  substitutions,  we  let 
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region  variables  match  via  implicit  renaming  of  bound  region  variables.^ 

The  rule  (Rl)  types  region  creation.  The  type  of  the  expression  is  an  existentially  quantified  region 
handle  type,  matching  the  reduction  rule  [Rl].  Existential  types  statically  distinguish  different  regions,  that 
is,  different  regions  are  assigned  different  region  variables  if  they  appear  free  in  a  piece  of  code.  For  a  reason 
similar  to  that  in  (FI)  and  (Tl),  the  condition  Y,  Z  G  L  is  required. 

The  rule  (R2)  types  region  deletion.  The  condition  Y  G  L  is  required  because  the  validity  bit  stored  in 
the  region  referred  to  by  Y  must  be  set  to  0  and  the  use  counter  needs  to  be  checked. 

The  rule  (R3)  types  manipulation  of  use  counters.  Since  the  use  counter  for  the  region  referred  to  by  X 
is  incremented  on  entry  into  62,  we  allow  62  to  access  X;  hence  62  is  type-checked  with  the  effect  L  U  {X}. 
The  use  counter  may  be  decremented  within  62,  but  this  does  not  pose  a  problem  because  it  must  be  the 
case  that  decrementing  happens  at  the  end  of  reducing  some  useregion  —  in  63  reachable  by  reducing  62. 
Therefore  the  use  counter  must  have  been  incremented  on  entry  to  63.  Therefore  it  follows  that  the  use 
counter  at  the  end  of  reducing  62  is  at  least  as  large  as  it  was  immediately  before  reducing  62  (in  this  case, 
they  are  actually  equal).  This  intuition  works  for  the  single-thread  case.  We  shall  formalize  the  argument 
later  so  that  it  works  even  for  multi-thread  programs. 

Given  a  program  e,  we  say  that  e  is  well-typed  iff  {Xgr};  {sr  1— s-  reg(Xsr)@Xsr}  b  e  :  r;  {Xgr}  for  some  r. 

All  the  rules  are  syntax  directed,  and  type  checking  is  clearly  decidable.  Readers  familiar  with  stack-of- 
regions  style  systems  should  be  able  to  easily  recognize  all  rules  except  for  (Rl),  (R2),  and  (R3). 

2.3  Example  1 

The  expression  below  shows  a  function  to  be  allocated  at  the  starting  region.  The  function  takes  a  region 
handle  of  any  region  r  (referred  to  by  X  in  the  function  body)  as  the  argument,  creates  a  new  region,  say  s, 
whose  region  handle  gets  allocated  in  r,  creates  another  new  region,  say  t,  whose  region  handle  gets  allocated 
in  s,  and  returns  both  of  the  new  region  handles  in  a  tuple  allocated  in  r. 

AX,YXx:reg{X)@Y. 

open  z  =  (newregion  at  x)  as  reg{Z)@X 
in  useregion  z 

in  pack  (z,  newregion  at  z)  at  x 
as  3Z.{reg{Z)@X,  3W.re5(W)@Z)@X 

at  sr 


The  expression  is  well-typed  and  the  allocated  function  has  the  type 

{yx,Y.reg{X)@Y  T)@X^r 
where  t  is  3Z.(reg(Z)@X,  3W.reg(W)@Z)@X. 

Now  let  us  use  this  function.  We  call  this  function  with  some  region  handle  and  then  delete  the  region  t 
returned,  which  requires  accessing  the  region  handle  for  t,  which  is  allocated  in  the  region  s,  which  is  itself 
allocated  by  the  function.  In  the  code  fragment  below,  assume  that  x  is  bound  to  some  region  handle  of 
type  reg{X)@Xsr  and  that  u  is  bound  to  the  function. 

useregion  x 

in  open  v  =  (u[X,  Xgr]  x)  as  {reg{Z)@X,  3W.reg(W)@Z)@X 
in  open  w  =  v.2  as  reg(W)@Z 

in  useregion  v.l  in  f reeregion w 

^We  could  use  this  argument  to  avoid  explicit  substitutions  in  (F2).  But  that  may  have  lead  to  confusion  in  case  one  region 
variable  is  used  to  simultaneously  rename  more  than  one  bound  region  variable. 
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2.4  Proof  of  Safety 

A  program  is  stuck  if  we  reach  a  state  (i?,  e)  such  that  e  is  not  a  value  and  also  cannot  be  reduced  further. 
We  show  that  if  a  program  is  well- typed  then  it  does  not  get  stuck,  which  implies  that  we  can  eliminate 
all  conditions  of  the  form  i?(r)  =  (1,  — )  in  the  hypotheses  of  the  reduction  rules  because  they  only  serve  to 
make  programs  get  stuck.  Also,  since  no  reduction  turns  a  validity  bit  from  0  to  1,  it  is  easy  to  see  that 
region  can  be  physically  deleted  once  its  validity  bit  goes  to  0,  that  is,  [R2]  may  actually  free  the  region  r. 
Hence  this  implies  that  a  well-typed  program  is  memory  safe. 

The  proof  is  in  the  style  of  [19].  For  the  proof,  we  must  be  able  to  type  intermediate  expressions.  To 
this  end,  we  extend  the  type  environment  so  that  it  can  map  regions  to  region  variables  (e.g.,  r(r)  =  X)  as 
well  as  variables  to  types.  We  omit  detailed  presentation  of  type  checking  rules  for  intermediate  expressions. 
However,  we  note  that  abort  has  any  type  under  any  environment  and  that  the  following  rule  is  used  to 
type-check  inuse’s: 

r(r)  =  X  r(s)=Y  A;r  h  e  :  t;LU  {X}  YGL 
A;  r  h  inuse  (reg  r  at  s)  in  e  :  t;  L 

We  need  the  following  definition  for  the  proof. 

Definition  1  A  state  {R,  e)  is  well-typed  under  the  environment  A;  F  iff 

(1)  dom{T)  =  dom{R),  ran{T)  C  A,  and  A;  F  h  e  :  — ;  {Xgr}- 

(2)  For  each  subexpression  of  the  form  A*A— :*.ei  at  —  of  e,  ei  does  not  contain  a  subexpression  of  the 
form  inuse  —  in—. 

(3)  For  each  r  G  dom{R)  such  that  r  xsr,  the  number  of  occurrences  of  subexpressions  of  the  form 
inuse  {reg  T  at—)  in  —  of  e  is  equal  to  i  where  i?(r)  =  (— ,t). 

(4)  If  R{r)  =  {b,i)  and  i  >  0  then  6=1. 

We  write  A;  F  h  {R,  e)  to  mean  that  {R,  e)  is  well  typed  under  A;  F.  Given  this  definition,  we  prove  the 
following  theorem. 

Theorem  1  (Subject  Reduction)  //Ai;Fi  h  (i?i,ei)  and  ^  i?2,e2,  then  there  exists  A2,F2  such 

that  A2; F2  F  (i?2, 62). 

Proof:  The  conditions  (2),  (3),  and  (4)  can  be  proven  independent  of  the  choice  of  A2,F2.  The  condition 
(2)  follows  from  inspection  of  the  reduction  rules.  Given  (2),  (3)  is  straightforward  by  inspection  of  [R4]  and 
[R6] .  The  condition  (4)  is  straightforward  by  inspection  of  [R4] . 

It  remains  to  find  A2  and  F2  to  satisfy  (1).  We  can  do  so  by  a  straightforward  case  analysis  on  the  redex 
using  the  substitution  lemma  and  the  replacement  lemma.  □  We  next  prove  the  following  theorem. 

Theorem  2  (Progress)  //  A;  F  h  {R,  e)  and  e  is  not  a  value,  then  there  is  a  reduction  from  {R,  e). 

Proof:  The  main  part  of  the  proof  is  in  showing  that  condition  of  the  form  R{.  ..)  =  ...  in  the  hypotheses 
of  each  reduction  rule  is  satisfied.  To  this  end,  we  need  the  following  lemma. 

Lemma  1  //A;F  h  E[e]  :  — ;  {Xgr}  then  there  is  a  sub-derivation  A;  F  h  e  :  — ;  L  such  that  if  X  €  L  and 
X  Xsr  then  there  is  an  occurrence  of  inuse  (reg  r  at  — )  in  —  in  E[e]  such  that  F(r)  =  X. 

The  lemma  can  be  proven  by  inspection  of  the  type  checking  rules.  Given  this  lemma,  we  can  show  by  (3) 
and  (4)  of  Definition  1  that  R{.  ..)  =  ...  is  satisfied.  □  It  is  easy  to  see  that  for  a  well-typed  program  e, 

we  have  {Xgr};  {rsr  X.sr}  F  ({rsr  (1, 1)},  e)  where  rsr  is  the  starting  region.  So  by  the  two  theorems 
above,  it  follows  that  a  well-typed  program  does  not  get  stuck,  that  is,  it  is  memory  safe. 

A  more  detailed  proof  for  the  extended  version  of  the  system  appears  in  Appendix  A.l. 


(Fl-m) 


A;  r  h  e  :  r;  L  A;  F  h  e  ;  reg{t)\L  X  £  L 
A;  r  h  e  at  e  :  r@X;  L 


(Tl-m) 


A;  r  h  62  :  reg(X);  L2  fregvars{Ti)  U  Li  C  A  tt)  {Y} 
Afe)  {Y};rfe)  {a;  1-^  n}  h  61  :  r2;Li  X  £  L2 

A;  r  h  AYAx:ri.6i  at  62  :  (VY.ri  r2)@X;  L2 


A;  r  h  newregion  at  :3X.re5(X);  L 


(Rl-m) 


A;  r  h  6  :  reg{X)-,  L 
A;  r  h  freeregion  6  :  reg{t)-,L 


(R2-m) 


A;rh6i  :reg(X);L  A;  F  h  62  :  r;  L  U  {X} 
A;  F  h  useregion  61  in  62  :  t;  L 


Figure  5:  Modifications  to  (Rl),  (R2),  and  (R3) 


3  Region  Handles  for  Free 

One  problem  with  the  system  as  described  thus  far  is  that  every  region  handle,  namely  the  use  counter  and 
the  validity  bit,  needs  to  be  allocated  in  a  separate  region  from  its  own  region  (except  sr).  This  problem 
leads  to  inconvenience.  For  example,  one  cannot  just  create  a  region  temporarily,  use  it,  delete  it,  and  then 
get  back  to  the  same  memory  state  because  the  system  leaves  the  region  handle  as  garbage.  In  order  to 
collect  this  garbage,  one  needs  to  delete  the  region  which  contains  this  region  handle,  which  leads  back  to 
the  same  problem. 

While  this  may  be  a  small  problem  in  practice  since  a  region  handle  takes  up  only  a  small  amount  of 
space,  it  may  become  a  serious  problem  for  severely  resource  limited  programs.  It  is  also  annoying  from 
the  technical  point  of  view;  in  almost  all  other  manual  region  systems,  a  region  handle  is  essentially  just  a 
pointer  to  the  head  of  the  region  and  hence  requires  no  separate  heap  space  (i.e.,  all  region  information  is 
stored  within  the  region  itself). 

In  this  section,  we  solve  this  problem  at  the  cost  of  a  small  run-time  overhead.  The  idea  is  to  modify 
the  basic  system  slightly  so  that  each  use  counter  is  allocated  within  the  region  itself  and  the  validity  bit  is 
dispensed  with.  Therefore  a  region  handle  no  longer  requires  a  separate  space,  and  deleting  a  region  does 
not  leave  a  garbage  region  handle. 

We  first  make  a  few  small  changes  to  the  language  to  reflect  the  fact  that  region  handles  are  self-allocated. 
We  replace  newregion  at  e  with 

newregion 

and  reg(X)@Y  with 

reg(X) 

We  also  change  the  intermediate  representation  of  a  region  handle  from  reg  r  at  s  to 

reg  r 

We  make  a  few  straightforward  changes  to  the  type  checking  rules  to  reflect  the  changes  we  made.  Figure  5 
shows  the  new  rules.  The  new  rules  are  slightly  simpler.  We  no  longer  need  the  starting  region,  so  we  get 
rid  of  sr  and  Xgr.  A  program  e  is  well-typed  iff  0;  0  h  e  :  — ;  0. 

Next,  we  introduce  a  new  intermediate  value  dr  of  type  reg(Xdr)  where  Xdr  is  a  special  region  variable. 
Note  that  the  constant  dr  is  not  available  to  source  programs. 

The  basic  idea  behind  the  modification  is  to  replace  each  reference  to  a  handle  of  a  deleted  region  with  dr. 
For  each  region  r,  the  run-time  system  maintains  two  data-structures  in  r  itself:  a  doubly  linked  list  called 
reglocsi(r)  and  a  singly  linked  list  called  reglocs2(r).  The  run-time  system  stores  pointers  to  all  occurrences 
of  reg  r  in  reglocsi(r).  In  addition,  for  each  region  s,  reglocs2(r)  stores  a  pointer  to  each  occurrence  of  reg  s 
allocated  within  r. 

More  concretely,  at  each  allocation  a  at  reg  r,  for  each  direct  occurrence  of  reg  s  in  a,  the  run¬ 
time  system  stores  the  address  of  the  occurrence  in  reglocsi{s)  and  in  reglocs2(r:) .  For  example,  evaluating 
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((reg  s,  reg  t)  at  r,  reg  t)  at  reg  r  allocates  an  element  containing  the  heap  location  of  the  second  element 
of  the  outermost  tuple  (the  second  reg  t)  in  reglocsi{t)  and  in  regZocs2 (r) .  Note  that  other  two  region 
handles  are  already  allocated  so  nothing  else  needs  to  be  done.  In  general,  for  a  tuple  (ui, . . . ,  «„)  at  reg  r, 
only  the  Vi  of  the  form  reg  r  needs  to  be  considered  assuming  that  we  treat  pack  •  as  x;  as  t.  A  similar 
treatment  is  done  when  allocating  function  closures,  that  is,  the  address  of  any  free  variable  bound  to  a 
region  handle  reg  t  gets  stored  in  reglocsi{t)  and  in  reglocs2{^)  when  the  closure  is  allocated  in  the  region 
r.  Region  handles  allocated  at  non-heap  locations  (e.g.,  stack  variables)  are  handled  similarly. 

A  region  handle  is  implemented  as  a  double- word  value.  This  implementation  choice  warrants  further 
discussion  later  in  the  section  (Section  3.2).  A  region  handle  reg  r  is  a  pair  of  pointers,  one  pointing  to  the 
head  of  the  region  r  and  the  other  pointing  to  the  element  of  reglocsi{T)  corresponding  to  this  reference. 

When  the  program  tries  to  delete  a  region  r  via  some  freeregion  reg  r,  the  run-time  system  loops 
over  each  element  of  reglocsiir)  overwriting  each  region  handle  with  dr.  Then  it  loops  over  each  element  of 
reglocs2(jo)  such  that  if  it  finds  a  region  handle  of  t  that  is  not  dr,  it  follows  the  pointer  to  an  element  of 
reglocsi{t)  and  deletes  the  element  from  the  doubly-linked  list.  Finally  the  region  r  is  deleted.  Similarly, 
when  a  non-heap  allocated  reference  to  a  region  handle  of  t  is  deallocated,  the  run-time  system  follows  the 
pointer  to  the  corresponding  element  of  reglocSi{t)  and  deletes  the  element. 

Now  the  use  counter  can  be  stored  within  the  same  region.  We  no  longer  need  the  validity  bit  as 
the  run-time  system  just  needs  check  for  dr  at  useregion’s.  The  run-time  system  pays  the  price  for  the 
modification  when  allocating  a  value  containing  a  reference  to  a  region  handle  and  when  deallocating  such  a 
reference.  As  we  shall  see  in  Section  3.2,  a  suitable  restriction  to  the  static  system  guarantees  that  no  other 
run-time  cost  needs  to  be  paid.  For  example,  the  run-time  system  does  no  extra  work  when  allocating  a 
value  that  contains  no  immediate  reference  to  a  region  handle.  Deleting  a  region  costs  time  proportional  to 
the  number  of  references  to  region  handles  allocated  in  that  region  and  references  to  its  region  handle,  which 
is  independent  of  the  number  of  other  type  of  values  and  should  be  a  small  factor  in  a  reasonable  region 
program.  Note  that  unlike  with  a  tracing  or  reference-counting  garbage  collector,  neither  operation  requires 
any  reachability  computation. 

3.1  Mutable  Values 

Suppose  that  we  extended  the  language  with  mutable  values.  In  order  to  maintain  the  invariants  just 
discussed,  when  a  reference  to  a  region  handle  of  r  is  modified  to  refer  to  a  region  handle  of  t,  the  run-time 
system  follows  the  pointer  to  an  element  of  reglocsi{T) ,  deletes  the  element  from  the  list,  and  then  allocates 
an  element  in  reglocsi(t)  containing  a  pointer  to  this  reference. 

3.2  Polymorphism 

In  order  to  allow  smooth  integration  of  our  system  with  a  polymorphic  language,  one  might  prefer  a  single¬ 
word  implementation  of  a  region  handle  as  opposed  to  the  double-word  implementation  described  above. 
This  can  be  accomplished  by  storing  a  pointer  to  the  head  of  the  region  r  in  each  element  of  reglocsi  (r)  and 
implementing  the  region  handle  as  a  pointer  to  the  corresponding  element.  This  change  incurs  an  extra-level 
of  pointer-lookup  at  allocation  sites. 

But  there  is  a  strong  reason  not  to  allow  instantiating  a  type  variable  with  a  region  handle  type  in  the 
presence  of  polymorphism.  The  problem  is  that,  at  allocation  sites,  the  run-time  system  needs  to  check  if 
a  value  whose  type  is  some  type  variable  (at  compile  time)  is  a  region  handle,  and  if  so  the  corresponding 
linked  lists  need  to  be  extended.  For  example,  when  allocating  a  value  of  the  type  (a,  reg(Y))@X  where  a 
is  a  type  variable,  the  run-time  system  needs  to  test  if  the  first  element  of  the  tuple  is  a  region  handle.  A 
similar  run-time  overhead  occurs  when  updating  a  mutable  value  that  has  a  type-variable  type. 

In  contrast,  if  we  forbid  abstraction  over  a  region  handle  type,  then  all  references  to  region  handles  will 
be  known  at  compile  time.  Note  that  programs  are  still  allowed  to  instantiate  a  “boxed”  type  that  contains 
a  region  handle  type  (e.g.,  a  heap-allocated  tuple  containing  a  region  handle:  T[{reg{'K) ,  reg{X))@Z / a]) .  This 
design  also  lets  us  keep  the  double-word  region  handle  implementation.  Because  unboxed  multi-word  values 
appear  to  be  important  for  efficient  manual  memory  management  in  a  full-scale  programming  language  [9], 
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having  a  region  handle  type  as  just  another  non-generalizable  type  might  not  cause  further  damage  to  the 
overall  uniformity  of  the  language. 

It  is  worth  noting  that,  in  case  one  wants  abstraction  over  region  handle  types  despite  its  shortcomings, 
it  is  possible  to  alleviate  the  run-time  overhead  via  static  analysis.  For  example,  a  flow  analysis  can  conser¬ 
vatively  estimate  which  value  may  not  evaluate  to  a  region  handle.  We  leave  the  choice  open  to  the  language 
designer. 


4  Analysis  and  Discussion 

In  this  section,  we  evaluate  our  use-counting  technique  analytically  and  discuss  several  pragmatic  issues. 
First,  we  show  an  efficient  encoding  of  stack-of-regions  style  memory  management  within  our  system  to 
show  that  use  counting  is  at  least  as  powerful  as  this  well-known  region  technique. 

4.1  Encoding  Stack-of- Regions 

Stack-of-regions  refers  to  a  region-based  memory  management  technique  where  each  region’s  lifetime  is 
bounded  by  the  lifetime  of  some  stack  frame.  This  technique  is  the  basis  of  many  region  proposals,  both 
manual  and  automatic  [15,  1,  9,  2]. 

In  this  paper,  we  are  concerned  with  the  manual  interpretation.  The  basic  manual  stack-of-regions  can  be 
obtained  by  removing  newregion,  freeregion,  and  useregion  from  our  small  region  language  and  adding 

letregion  x  as  reg(X)  in  e 

Reducing  this  expression  creates  a  new  region  referred  to  by  X,  substitutes  the  region  handle  of  the  new 
region  for  x  in  e,  reduces  e  to  a  value  v,  deletes  the  region,  and  then  returns  v. 

The  type  checking  rule  is 

A  l±)  {X};  r  l±)  {x  1-^  reg{X)}  h  e  :  t;  L  U  {X} 
fregvars{T)  C  A 

A;  F  h  letregion  x  as  reg(X)  in  e;  r;  L 

We  show  that  letregion  can  be  efficiently  encoded  using  newregion,  freeregion,  and  useregion.  Let 
ei;  62  be  an  abbreviation  for  let  x  =  ei  in  62  where  x  ^  fvars{e2)-  Now  consider: 

open  X  =  (newregion)  as  reg{X) 

in  let  y  =  (useregion  x  in  e)  in  freeregion  x;  y 

It  is  easy  to  see  that  this  encoding  has  the  same  behavior  as  letregion.  That  is,  before  entering  e,  a  new 
region  is  created  and  bound  to  x,  then  after  e  reduces  to  a  value,  the  region  is  deleted.  It  is  also  easy  to  see 
that  the  encoding  preserves  well-typedness. 

The  resulting  program  is  efficient.  There  is  only  a  constant  time  overhead  for  each  occurrence  of 
letregion.  That  is,  before  evaluating  the  body,  a  new  region  and  its  use  counter  is  allocated,  and  the 
use  counter  is  incremented  after  checking  that  the  region  has  not  been  deleted.  Once  the  body  evaluates, 
the  use  counter  is  decremented,  and  the  region  is  deleted  after  checking  that  the  use  counter  is  0. 

It  is  easy  to  see  that  a  translated  stack-of-regions  program  will  never  abort. 

4.2  Dynamic  Check  Failures 

However,  the  full  potential  of  use  counting  is  realized  when  the  program  does  not  use  regions  in  a  stack-wise 
order.  For  example,  stack-of-regions  is  insufficient  to  express  the  example  in  Section  2.3  since  every  function 
is  forced  to  delete  all  regions  it  creates  before  it  returns. 

In  the  general  case,  however,  programs  do  not  enjoy  the  abort-free  property.  But  we  argue  that  it  is  rare 
that  a  well-written  program  encounters  a  dynamic  check  failure.  Recall  that  there  are  two  kinds  of  dynamic 
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checks:  the  dr  check  (or  the  validity  bit  check)  at  useregion  and  the  use  counter  check  at  freeregion. 
Consider  a  situation  in  which  the  first  check  fails,  that  is,  useregion  reg  r  in  e  is  encountered  after  the  region 
r  has  been  deleted.  Suppose  that  the  programmer  adheres  to  the  discipline  that,  by  useregion  reg  r  in  e, 
he/she  means  that  r  is  definitely  going  to  be  used  in  e.  Then  a  dynamic  check  failure  indicates  a  real 
programming  bug  instead  of  a  spurious  dynamic  check  failure  since  r  was  deleted  before  executing  the  code 
which  was  supposed  to  use  r. 

On  the  other  hand,  the  second  dynamic  check  fails  when  freeregion  reg  r  is  encountered  within  some 
context  inuse  reg  r  in  if  (at  least  for  the  single-thread  case).  This  type  of  failure  is  harder  to  characterize. 
But  it  is  worth  noting  that  conservatively  detecting  such  failures  at  compile  time  is  possible  to  some  degree 
via  known  static  analysis  techniques.  For  example,  a  variation  of  the  algorithm  from  [5]  could  be  used  to 
produce  compile-time  warnings  for  potentially  dangerous  freeregion  occurrences.  Also,  this  type  of  failure 
is  easier  to  recover  from,  since  the  worst  the  programmer  could  do  is  to  ignore  and  leak  memory. 

4.3  Annotation  Cost 

To  use  the  system,  the  programmer  needs  to  annotate  code  with  useregion  constructs  in  addition  to  writing 
type  and  effect  annotations.  Somewhat  surprisingly,  useregion  and  type  and  effect  annotations  are  mutually 
compensating.  Intuitively,  the  more  useregion  annotations  the  programmer  writes,  the  fewer  type  and  effect 
annotations  required. 

To  illustrate  this  point,  consider  a  large  block  of  code  eg  that  uses  many  regions,  say  r ,  s ,  ....  Assume 
that  Co  does  not  delete  these  regions.  Then  it  is  a  good  idea  to  wrap  eg  with  corresponding  useregion’s  to 
amortize  the  cost  of  dynamic  checks  since  eg  is  large.  That  is, 

useregion  ei 
in  useregion  62 

in  useregion  ...  in  eg 

where  ei,  62,  . .  .are  region  handles  for  r,  s,  .  .  .,  respectively.  Now  consider  a  function  which  contains 
eg  as  a  subexpression,  say,  AxiTi.eg  at  —  for  the  sake  of  brevity.  Then,  the  type  of  this  function  is  just 

(ti  — ^  T2)@X  for  some  T2  and  X  assuming  that  eg  uses  no  other  regions. 

In  general,  an  occurrence  of  useregion  eliminates  the  corresponding  region  variable  from  the  effect  sets 
of  the  parent  expressions,  which  in  turn  relieves  the  programmer  from  having  to  annotate  them  in  the 
corresponding  effect  sets.  We  can  see  a  glimpse  of  this  property  in  action  in  the  examples  in  Section  6  where 
every  function  has  a  rather  trivial  effect  set  annotation.  This  property  also  has  an  compounding  benefit 
because  a  context  calling  such  function  requires  neither  useregion  nor  effect  annotations  for  the  regions 
accessed  by  the  callee.  This  is  in  contrast  to  conventional  region-based  approaches  where  function  types  are 
required  to  carry  identifications  of  all  non-local  regions  accessed  by  the  function  (up  to  abstraction  over  sets 
of  region  identifiers). 

On  the  other  hand,  for  run-time  efficiency,  it  is  desirable  to  leave  the  body  of  a  short-running  function 
free  of  useregion’s.  Such  a  small  function  is  likely  to  use  few  regions,  and  therefore  the  effort  required  to 
annotate  its  effect  set  is  correspondingly  small. 

The  system  presented  in  this  paper  is  explicitly  typed.  While  outside  of  the  scope  of  the  paper,  it  is  easy 
to  see  that  inferring  type  and  effect  annotations  is  possible  with  some  suitable  restrictions.  Some  amount  of 
inference  (e.g.,  in  the  spirit  of  local  type  inference  [13])  will  be  important  for  incorporating  use  counting  in 
a  full-scale  programming  language. 


5  Regions  and  Threads 

A  problem  common  with  many  manual  memory  management  systems  is  that  they  have  difficulty  supporting 
multi-threading  while  retaining  safety  and  controllability.  Consider  the  stack-of-regions  approach.  To  handle 
thread-shared  memory,  the  run-time  system  must  be  aware  of  threads  that  may  potentially  access  a  region 
so  that  the  region  may  be  deleted  only  after  all  potentially  accessing  threads  terminate.  If  the  thread  that 
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allocated  the  region  is  allowed  to  continue  after  the  stack  pops  regardless  of  future  behavior  of  other  threads, 
then  memory  behavior  becomes  difficult  to  control  because  the  lifetime  of  the  region  is  no  longer  tied  to  the 
lifetime  of  the  stack  but  to  the  longest  living  thread  having  access  to  the  region.  On  the  other  hand,  if  the 
thread  that  allocated  the  region  is  forced  to  stall  until  it  is  safe  to  delete,  then  the  run-time  behavior  of  the 
allocating  thread  becomes  less  predictable. 

Thread-based  concurrency  is  common  in  many  modern  programs.  One  of  the  nicest  features  of  the 
use-counting  approach  is  that  thread-based  concurrency  is  supported  for  free. 

We  extend  the  small  region  language  with  the  form  fork  e  and  extend  the  dynamic  semantics  with 
concurrently  executing  threads.  Each  state  has  the  form  (i?,  e)  where  each  €  e  is  a  thread.  Reductions 
are  still  from  states  to  states,  and  each  reduction  rule  can  be  applied  to  any  thread  in  e.  The  reduction  rule 
for  f  ork  e  is 

R,  (el,  if  [fork  e],  el)  — >  R,  (el,  if  [unit],  el,  e) 

where  the  constant  unit  is  a  place  holder  value  of  type  unit.  The  type  checking  rule  for  fork  e  is 

A;  r  h  e  :  r;  0 
A;  r  h  fork  e  :  unit;  L 


No  other  changes  are  needed. 

The  argument  used  in  the  proof  of  safety  for  the  sequential  case  still  works.  The  key  observation  is  that 
the  proof  of  safety  was  based  on  the  number  of  syntactic  occurrences  of  inuses.  Hence  to  prove  safety  for 
multi-thread  case,  we  can  simply  add  up  the  number  of  inuses  from  all  threads  and  compare  the  sum  with 
the  use  counter  in  the  region  map.  Since  A;  T  h  e  :  r;  0  and  since  e  does  not  contain  any  inuse,  the  newly 
forked  thread  e  satisfies  the  invariants  in  Definition  1,  and  therefore  the  induction  argument  goes  through. 
Appendix  A.l  discusses  the  reasoning  in  more  detail. 

As  in  the  single-thread  case,  deleting  a  region  while  being  used  or  trying  to  use  a  region  that  has  been 
deleted  results  in  a  dynamic  check  failure.  The  difference  is  that  such  situations  may  now  involve  concurrently 
running  threads,  for  example,  when  thread  A  attempts  to  delete  some  region  that  thread  B  is  using.  To  avoid 
dynamic  check  failures,  programs  must  synchronize  threads  so  that  region  uses  and  deletions  are  correctly 
scheduled. 

How  such  synchronization  is  done,  whether  explicitly  by  the  programmer  or  implicitly  by  concurrency 
abstractions  in  the  programming  language,  is  another  issue.  Our  proposal  provides  a  simple  and  sound  basis 
for  incorporating  safe  memory  management  with  any  synchronization  mechanism. 


6  Experience  with  Regions 

We  informally  discuss  our  experience  with  a  toy  implementation  of  the  technique.  Instead  of  creating  an 
entirely  new  language  from  scratch,  we  extend  an  existing  language  with  use-counted  regions.  We  choose 
C  for  this  purpose,  mainly  because  we  had  prior  experience  with  manual,  though  sometimes  unsafe,  region 
programming  in  this  language. 

The  ideal  goal  is  to  replace  malloc  and  free  with  newregion  and  freeregion.  But  more  realistically, 
our  implementation  provides  use-counted  regions  as  a  safe  alternative  while  keeping  the  rest  of  C  available 
and  unsafe.  Hence  we  leave  features  such  as  casting  in  the  language.  The  implementation  covers  only 
the  monomorphic  fragment  of  the  system.  (Monomorphic  as  in  the  sense  of  Section  2,  and  so  we  do  permit 
quantification  over  region  variables.)  However,  we  support  non-heap-allocated  records  in  the  form  of  structs, 
which  turns  out  to  be  useful  for  writing  short  but  interesting  examples.  One  reason  for  this  section  is  to 
provide  ample  examples  in  easy-to-read  syntax.  The  examples  are  designed  to  illustrate  the  expressive  power 
of  our  system  such  that  other  safe,  explicit  memory  management  approaches  would  have  difficulty  expressing 
them. 
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6.1  Syntax 

The  basic  scheme  is  identical  to  that  of  the  small  region  language.  The  built-in  function  region  newregion(void) 
creates  a  new  region  and  returns  its  region  handle,  and  the  built-in  function  void  freeregion (region) 
deletes  the  region  passed.  We  also  have  useregion,  which  is  now  written  useregion(ei)  {  62  }. 

However,  C  has  a  number  of  differences  with  the  lambda  calculus  (to  put  it  mildly)  which  dictate  a 
somewhat  different  design.  The  major  changes  are: 

1  Instead  of  the  notation,  we  now  indicate  where  a  value  is  stored  as  part  of  its  pointer  type.  For 
example,  int  *  X  is  a  pointer  to  an  integer  in  region  referred  to  by  X.  We  allow  NULL  to  have  any  pointer 
type. 

2  We  use  syntax  resembling  C-I--I-  templates  to  write  data  structure  types  parametrized  by  region  variables. 

struct <X>structname{  def  } 

The  region  variables  X  are  binding  occurrences,  and  therefore  X  may  appear  free  in  def.  For  such  a  type  r, 
its  region  variables  can  be  instantiated:  t<X>.  What  is  unique  about  our  struct’s  is  that  when  it  is  not 
instantiated,  the  value  is  said  to  be  closed,  which  intuitively  represents  an  existential  type  abstracted  over 
the  bound  region  variables.  For  example,  a  newly  created  region  handle  has  the  type  region  and  is  therefore 
closed. 

For  example,  the  type  IntCell  consisting  of  a  region  handle  reg  to  some  region  r  and  a  pointer  data 
pointing  to  an  integer  allocated  in  r  is  written  as 

struct<Z>  IntCell  {  region<Z>  reg;  int  *  Z  data  }; 

An  instantiated  type  can  be  closed  at  any  time,  which  intuitively  represents  pack. 

3  The  built-in  polymorphic  function 

T  *  X  ralloc (region<X> ,t)  {X} 

allocates  values  of  type  r  in  the  region  passed  and  returns  a  pointer  to  the  allocated  memory  block.  Allocated 
memory  blocks  are  initialized  to  zero.  The  set  {X}  denotes  the  latent  effect  of  the  function.  Latent  effect 
annotations  are  omitted  for  functions  whose  latent  effect  is  0. 

4  We  use  C  conventions  of  compound  statement  scope.  For  example,  to  open  e  of  closed  type  t  by 
instantiating  it  with  region  variables  X,Y,Z,  write 

open  t<X,Y,Z>  x  =  e; 

Then  X,Y,Z  are  new  region  variables  that  are  available  in  the  current  scope.  The  variable  x  is  forced  to  be 
const. 

5  We  drop  explicit  polymorphic  functions.  Instead,  every  function  is  always  implicitly  polymorphic  in  free 
region  variables  appearing  in  its  return  type,  argument  types,  and  latent  effect  because  C  functions  are 
always  defined  at  the  top  level.  Functions  are  instantiated  at  the  call-sites. 
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struct  elt  { 

struct<X>  wrapper  { 
region<X>  reg; 
struct  elt  *  X  next; 

}  wrap; 
int  data; 

}; 

void  insert (struct  elt  *  X  cur,  int  newdata)  {X}  { 
open  region<Y>  newreg  =  newregionO; 
struct  elt  *  Y  newelt; 
useregion(newreg)  { 

newelt  =  ralloc (newreg,  struct  elt); 
newelt->data  =  newdata; 
newelt->wrap  =  cur->wrap; 

} 

cur->wrap  =  {reg: newreg,  next : newelt} ; 

} 

void  delete (struct  elt  *  X  cur)  {X}  { 
open  struct  wrapper<Y>  cw  =  cur->wrap; 
useregion(cw.reg)  { 

cur->wrap  =  cw.next->wrap; 

} 

freeregion(cw.reg) ; 

} 

void  print_list (struct  wrapper  list)  { 
do  {  open  struct  wrapper<X>  cw  =  list; 
if  (cw.next  ==  NULL)  return; 
useregion(cw.reg)  { 

printf  (  '7,d'  ,  cw.next->data)  ; 
list  =  cw.next->wrap; 

}  }  while  (1) ; 

} 

Figure  6:  Element-wise  deallocatable  linked  list 

6.2  Example  2:  Linked  List 

Element-wise  deallocatable  linked  lists  can  be  implemented  in  our  system  with  full  imperative,  destructive 
goodness  expected  from  lists  in  C.  To  this  end,  we  use  one  region  per  list  element;  the  definition  of  elt 
in  Figure  6  shows  that  a  list  element  consists  of  a  region  handle,  a  next  pointer,  and  a  content  data.  The 
content  data  is  just  an  integer,  so  the  example  is  probably  not  an  economical  use  of  regions:  it  is  just  for 
demonstration . 

Figure  6  shows  three  functions  that  do  insertion,  delete,  and  list  printing,  respectively.®  Note  that  deleting 
a  list  element  actually  deallocates  the  space  for  the  element  while  keeping  the  rest  of  the  list  intact.  All 
functions  are  written  in  an  imperative  fashion  common  in  C  programs;  there  is  no  need  to  rebuild  the  list 
when  an  element  is  inserted  or  deleted. 

Now  suppose  instead  of  an  integer  as  a  list  element,  we  want  a  large  data  structure  potentially  consisting 
of  many  connecting  pointers.  Suppose  that  this  data  structure  is  to  be  allocated  in  the  same  region  where 

®The  last  statement  in  insert  is  not  valid  C  syntax  because  .  .  .=  {.  .  .}  can  be  used  only  for  initializations.  This  can 
be  overcome  by  either  extending  C  or  adding  an  extra  scope  at  the  end  initializing  a  new  variable  of  type  elt  which  gets 
immediately  assigned  to  cur->wrap. 
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struct<X>  gen  { 
region<X>  reg; 
struct  gEmie<X>  *  X  g; 

}: 

struct  gen  nextgen(struct  gen) ; 
struct  gen  life(int  n,  struct  gen  g)  { 
if  (n  ==  0)  {  return  g;  } 
else  { 

struct  gen  newg  =  nextgen(g) ; 

open  struct  gen<X>  x  =  g;  f reeregion(x . reg) ; 

return  life(n-l,  newg); 

} 


Figure  7:  Game  of  Life  simulation 


the  element  is  allocated  (at  the  element  creation  or  later).  To  this  end,  we  need  a  region  variable  referring 
to  the  region  where  the  element  is  allocated.  We  add  a  new  binding  region  variable  in  the  definition  of  elt 
and  using  this  binding  to  equate  the  region  where  this  instance  of  elt  is  allocated  and  the  region  where  the 
data  structure  is  (or  is  going  to  be)  allocated. 

The  updated  definition  of  a  list  element  appears  below.  The  struct  type  data_type  (the  definition  not 
shown)  is  instantiated  with  Y  for  pointers  to  values  that  consist  this  data  structure. 

struct<Y>  elt  { 

struct<X>  wrapper  { 
region<X>  reg; 
struct  elt<X>  *  X  next; 

}  wrap ; 

struct  data_type<Y>  *  Y  data; 

}: 


6.3  Example  3:  Game  of  Life 

An  example  simulating  the  Game  of  Life  for  n  iterations  is  used  in  [10]  to  illustrate  varying  expressiveness 
of  different  region  systems.  In  Figure  7,  we  show  a  use  counting  implementation  which  closely  matches  the 
original  code  found  in  their  paper.®  The  function  nextgen  creates  and  returns  the  new  generation. 

The  resulting  function  life  satisfies  both  of  the  two  criteria  suggested  by  their  paper:  it  is  tail  recursive 
and  does  not  have  the  region  endomorphism  problem  (i.e.,  using  the  same  region  to  allocate  the  generations, 
which  leads  to  memory  leak). 

6.4  Existing  Region  Programs 

We  also  looked  at  several  existing  G  programs  that  use  regions  (safely  or  not)  to  do  part  of  their  memory 
management  and  found  that  use  counting  seems  capable  of  expressing  many  region  usage  patterns  found  in 
these  programs. 

One  common  pattern  found  in  several  programs  is  that  there  are  a  fixed  number  of  regions  existing  at  any 
time,  and  these  regions  are  stored  in  global  variables  (or  accessed  by  calling  global  functions).  For  example, 
Icc,  a  G  compiler,  uses  three  regions  placed  in  a  global  array  of  size  three  called  arena:  one  for  functions, 
one  for  statements,  and  one  permanent  region.  The  region  deletion  function  deallocate (int  i)  is  called 

®[10]  also  allocates  the  integer  argument  n  in  the  heap.  Here  we  just  stack-allocate  it  for  brevity. 
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to  delete  the  current  arena  [i]  after  each  function  (or  each  statement)  is  compiled.  Each  arena  [i]  (except 
of  course  the  permanent  one)  is  assigned  a  newly  created  region  before  the  next  allocation  in  arena  [i] . 

It  is  easy  to  express  such  a  pattern  in  our  system.  We  store  the  region  handle  with  the  data  in  a  globally 
accessible  closed  struct  and  open  it  wherever  the  data  is  requested.  We  reset  the  region  by  deleting  the 
region,  creating  a  new  one  and  closing  it  in  a  struct,  and  assigning  the  closed  value  to  the  same  global 
variable. 

Because  most  of  these  programs  are  neither  written  to  use  regions  for  safety  nor  pressured  with  tight 
space  or  timing  requirements,  they  do  not  contain  too  many  exciting  region  usage  patterns.  But  it  gives  us 
some  practical  evidence  for  the  technique’s  usability. 

7  Related  Work 

Ruggeieri  et  al.  [14]  introduced  the  stack-of-regions  concept,  and  Tofte  et  al.  [15]  extended  it  to  work  with 
higher-order  functions  and  polymorphic  regions.  Both  systems  were  formulated  for  automatic  memory  man¬ 
agement,  but  manual  variants  of  the  idea  have  also  been  proposed  [9,  2] .  We  have  given  a  detailed  comparison 
of  use-counted  regions  versus  stack-of-regions  in  the  earlier  parts  of  the  paper.  We  should  note  that  issues 
that  are  not  formally  discussed  in  the  main  body  of  our  paper,  such  as  parametric  polymorphism  over  types 
and  effect  sets,  recursive  types,  non-heap  allocated  values,  and  mutable  values,  have  been  extensively  studied 
in  the  aforementioned  papers.  It  is  straightforward  to  incorporate  these  features  formally  into  our  system 
in  much  the  same  way,  due  partly  to  the  fact  that  we  use  a  similar  framework  (with  the  minor  exception  of 
the  issue  discussed  in  Section  3.2).  Appendix  A  shows  the  small  region  language  extended  with  ML-style 
mutable  refs  and  parametric  polymorphism  over  types  and  effect  sets. 

Hicks  et  al.  have  developed  a  similar  technique  called  dynamic  regions  independently  from  our  work 
around  the  same  time.  In  [II],  they  briefly  outline  this  technique  along  with  two  other  memory  management 
ideas  that  are  of  independent  interest.  Their  dynamic  regions  can  be  roughly  interpreted  in  our  small 
region  language  by  assuming  that  region  handles  are  always  existentially  packed.  Opening  such  package  in 
their  system  corresponds  to  open  immediately  followed  by  useregion.  They  have  incorporated  dynamic 
regions  in  Cyclone  [9]  and  report  positive  results.  Compared  to  their  work,  our  paper  offers  the  following 
contributions:  a  formal  presentation  of  the  technique  and  the  proof  of  soundness,  analysis  and  discussion 
including  the  exposition  on  multi-threading  support,  and  the  following  two  technical  differences  regarding 
region  handles.  As  mentioned,  Hicks  et  al.’s  formulation  ties  dynamic  operations  on  region  handles  to 
existential  types,  whereas  we  use  an  arguably  more  natural  formulation  which  treats  existential  types  as 
purely  a  static  construct  as  in  the  standard  type  theory.  In  addition  to  being  somewhat  cleaner  in  theory,  our 
formulation  has  practical  advantages.  For  example,  our  system  allows  two  different  existential  abstractions 
over  the  same  region  handle,  which  in  turn,  for  example,  enables  sharing  of  a  region  among  different  data 
structures  without  having  to  syntactically  equate  the  region  variables.  The  second  difference  is  the  extension 
shown  in  Section  3  which  allows  a  region  handle  to  be  allocated  within  its  own  region. 

Walker  et  al.  [18]  combine  regions  with  linear  types  to  create  a  static  system  that  allows  interesting  region 
usage  patterns.  In  their  system,  each  region  handle  must  be  linear  when  the  region  is  deleted  and  non-linear 
(and  therefore  allowed  to  be  aliased)  when  the  region  needs  to  be  accessed.  Wadler’s  let! -like  construct 

[16]  turns  a  linear  region  handle  non-linear  in  a  designated  scope  and  then  back  to  linear  when  exiting  the 
scope.  Walker  et  al.’s  system  uses  these  linear/non-linear  phases  to  statically  prevent  a  region  from  being 
deleted  while  program  is  in  one  of  its  non-linear  scopes.  Hence  the  underlying  idea  is  somewhat  similar  to 
our  useregion,  and  so  our  use-counting  method  may  be  viewed  as  a  way  to  remove  limitations  imposed 
by  linear  types  by  inserting  dynamic  checks.  Their  paper  also  shows  how  to  integrate  a  reference-counting 
interpretation  of  linear  types  [3]  with  regions. 

Crary  et  al.  [4]  present  a  region  system  that  uses  the  notion  of  linearity  to  statically  track  aliasing  of 
region  handles.  Their  system  is  very  expressive  but  seems  to  require  non-trivial  program  annotations,  for 
example,  when  deallocating  individual  elements  of  recursive  data  structures  ala  our  example  in  Section  6.2 

[17] .  However,  their  intention  is  not  to  expose  the  region  system  at  the  source  level  but  instead  to  certify 
memory  safety  of  intermediate-level  code. 
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Henglein  et  al.  [10]  takes  a  different  approach  toward  region-based  memory  management  by  employing  a 
Floyd-Hoare  style  proof  system.  Their  primary  goal  is  to  create  an  automatic  system  for  a  conventional  non¬ 
region  language  ala  [15,  1].  Hence  their  system  is  not  meant  to  be  exposed  to  programmers  and  also  not  quite 
as  manual  as  the  systems  discussed  above.  In  particular,  there  is  no  language  construct  to  explicitly  delete  a 
region.  Instead,  the  system  maintains  reference  counts  on  region  handles^  so  that  a  region  is  automatically 
deleted  when  the  reference  count  becomes  zero.  To  this  end,  they  use  a  reference-counting  scheme  similar 
in  spirit  to  the  one  in  [3].  It  is  left  open  whether  their  system  could  be  extended  to  handle  function  closures 
and  polymorphism. 

In  contrast.  Gay  et  al.  [6]  uses  reference  counting  as  the  main  device  for  memory  safety  by  counting 
references  to  the  content  of  regions  in  addition  to  region  handles.  Their  system  allows  explicit  deletion  of 
regions  but  does  not  statically  guarantee  its  success,  similar  to  our  f  reeregion.  Their  system  demands  very 
little  from  the  static  side,  relying  largely  on  dynamic  reference  counting  for  safety.  To  recover  efficiency, 
they  use  compile-time  optimization  to  reduce  the  number  of  reference-counting  operations  and  also  provide 
optional  type  qualifier  annotations  to  help  the  optimizing  compiler. 

This  reference-counting  approach  is  related  to  use  counting  in  the  following  way.  Both  approaches  count 
the  “users”  of  each  memory  location  so  that  the  memory  location  may  be  deallocated  only  when  the  number 
of  users  is  zero.  For  efficiency,  both  frameworks  group  memory  locations  via  regions  to  reduce  the  number  of 
counters.  The  difference  between  the  two  approaches  is  in  the  meaning  of  a  “user”:  in  the  reference-counting 
approach,  a  user  is  a  pointer  pointing  to  the  region  whereas  in  our  approach,  a  user  is  a  piece  of  code  that  is 
actually  using  the  region  as  in  accessing  memory  locations  in  the  region.  Hence  to  group  memory  locations, 
the  reference-counting  approach  prefers  connecting  pointers  to  be  in  the  same  group,  whereas  our  approach 
encourages  grouping  memory  locations  that  are  accessed  together  in  the  same  piece  of  code.  This  observation 
has  led  us  to  coin  the  term  “use  counting”  to  describe  our  technique. 

Our  use-counting  approach  has  the  following  advantages  over  the  reference-counting  approach.  One  is 
that  we  do  not  require  the  references  to  be  dead  for  a  region  to  be  deleted.  Another  advantage  is  that,  when 
deciding  which  locations  should  be  grouped  together  in  a  region,  use  counting  can  capitalize  directly  on  the 
program’s  memory  access  pattern  instead  of  being  dependent  on  the  points-to  relationship. 


8  Conclusion 

We  have  presented  a  new,  mostly-static,  safe  region-based  memory  management  technique.  Our  method 
scales  naturally  to  a  variety  of  modern  language  features,  including  multi-threading,  and  offers  flexible 
manual  control  while  being  relatively  simple.  We  hope  to  have  provided  a  new  insight  into  designing  high- 
level  languages  for  resource-conscious  applications. 
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U,  V,  W,  X,  Y,  Z  e  RegVars  U  {Xsr}  u,  v,  w,  x,  y,  z  G  Vars  U  {sr}  r,  s,  t  G  Regions 
a,  b,  c  G  TypeVars  A,  B,  C  G  Effect  Vars  k,  l,m  G  Locations 


static  vars  a 

instantiations  7 

effect  sets  L 

types  T 

expressions  e 


a  1  A  1  X 
r|L|X 

0  I  LU{X}  I  LUA 

(Va.ri  — ^  r2)®Y  |  r@X  |  reg(X)@Y  |  3a. r  |  ttnif  |  A  |  ref{T)@X 

X  I  let  X  =  ei  in  62  I  AaAxir.ei  at  62  |  ei[7]  62  |  e  at  e  |  e.i  |  pack  e  as  3a. r  |  open  x  =  ei  as  r  in  62 
newregion  at  e  |  freeregion  e  |  useregion  ei  in  62  |  fork  e  |  ref  ei  at  62  |  !  e  |  ei  :=  62 

Figure  8:  Extended  small  region  language:  source  syntax 


values  V 

expressions  e 


pack  t  as  •  I  A»Ax;».e  at  r  |  -y  at  r  |  reg  r  at  s  |  abort  |  unit  |  loc  1  at  r 

x  I  let  x  =  61  in  62  I  A»Ax:».6i  at  62  |  6i[»]  62  |  e  at  e  |  e.i  |  pack  6  as  •  |  open  x  =  61  as  •  in  62  | 
newregion  at  e  |  freeregion  6  |  useregion  61  in  62  |  w  |  inuse  (reg  r  at  s)  in  6  | 
fork  6  I  ref  61  at  62  |  !  6  |  61  :=  62 


contexts  E  ::=  [  ]  |  let  x  =  E  in  e  |  A»Ax:».e  at  E  \  E[»]  e  |  w[«]  E  \ 

(if,  E,  e)  at  6  I  y  at  E  I  pack  E  as  •  |  open  x  =  E  as  •  in  e  | 

newregion  at  E  |  freeregion  E  |  useregion  E  in  6  |  inuse  (reg  r  at  s)  in  E  | 
ref  E  at  6  I  ref  yatE|  !E|E:  =  e|  (loc  1  at  r)  :  =  E 


Figure  9:  Extended  small  region  language:  type-erased  intermediate  expressions  and  evaluation  contexts 

A  Imperative,  Concurrent  and  Polymorphic  Small  Region  Lan¬ 
guage 

Figure  8  shows  the  small  region  language  extended  with  quantification  over  type  and  effect  variables  and 
ML-style  mutable  refs.  Recursive  functions  can  be  easily  expressed  using  refs.  We  also  formally  add  the 
multi-thread  extension  discussed  in  Section  5.  Figure  9  shows  the  corresponding  type-erased  intermediate 
expressions  and  evaluation  contexts.  For  the  purpose  of  exposition,  we  stick  with  the  notation  from  Section  2 
and  do  not  use  the  extension  described  in  Section  3. 

The  dynamic  semantics  is  a  series  of  small-step  reductions  from  states  to  states  where  state  is  a  triple 
(S',  R,  e)  where  S  is  a  store  mapping  each  location  1  in  its  domain  to  a  value.  For  brevity,  we  define  the 
multi-thread-e valuation  context: 

T  ::=  (el,E,  e^) 

Figure  10  shows  the  corresponding  reductions  rules. 

Figure  11  shows  the  type  checking  rules  for  the  source  language.  A’s  may  contain  type  variables  and 
effect  variables  in  addition  to  region  variables.  The  set  fvars{'j)  denotes  the  set  of  free  static  variables  (i.e., 
region  variables,  type  variables,  and  effect  variables)  in  7.  The  bound  static  variables  that  appear  in  a 
function  type  are  assumed  to  be  distinct.  We  assume  that  substitution  (F2-e)  matches  not  only  the  number 
of  static  variables  against  the  instantiations  but  also  their  kinds,  and  similarly  for  (El-e)  (i.e.,  each  type 
variable  is  substituted  by  a  type,  each  region  variable  is  substituted  by  a  region  variable,  and  each  effect 
variable  is  substituted  by  an  effect  set).  The  relation  Li  C  L2  is  defined  as  follows: 

El  C  E2  E3  Cl  E4 
A  CZ  A  0  CZ  A  El  U  E3  CZ  E2  U  E4 

in  addition  to  the  usual  axioms  for  the  set  theoretic  interpretation  of  C .  We  also  assume  that  A  U  A  =  A  and 
that  U  is  commutative  and  associative. 
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i?(r)  =  (l,-) 


R{s)  =  {!,-) 


S,  R,  r[A»Ax:».e  at  (reg  r  at  s)]  ^  S,  R,  r[A»Ax:».e  at  r] 


[Fl-e] 


i?(r)  =  (!,-) 


S,  R,  T[open  X  =  (pack  v  as  •)  as  •  in  e]  ^  S,  i?,  T[e[t/x]] 
i?(s)  =  (!,-) 


[E-e] 


5, -R,  r[(A»Ax:».e  at  r)[»]  t]  ^  S,  R,  r[e[w/x]] 
R(r)  =  (!,-)  R(s)  =  (!,-) 


S,  R,  T[newregion  at  (reg  r  at  s)] 

^  S',  R  W  {t  1-^  (1,  0)},  T[pack  (reg  t  at  r)  as  •] 


[F2-e] 

—  [Rl-e] 


S,  R  tfJ  {r  1-^  (— ,  0)},  r[freeregion  (reg  r  at  s)] 

^  S,  R  W  {r  1-^  (0,  0)},  r[reg  r  at  s] 


[R2-e] 


R(s)  =  (!,-) 


i  >  0 


S,  R  tt)  {r  1-^  (— ,  i)},  r[freeregion  (reg  r  at  s)] 

^  S,  R  ttl  {r  1-^  (— ,  i)},  abort 


R(s)  =  (!,-) 


S,  R  W  {r  1-^  (1,  i)},  ^[useregion  (reg  r  at  s)  in  e]  ^  R  W  {r  (1,  i  +  1)},  Rlinuse  (reg  r  at  s)  in  e] 
R{^)  =  ih-)  R(s)  =  (!,-) 


[R4-e] 


S,  R  W  {r  I— >  (0,  i)},  r[useregion  (reg  r  at  s)  in  62] 
—>  S,RW  {r  (0,  i)},  abort 


[R5-e] 


R(r)  =  (!,-) 


R(s)  =  (!,-) 


S,  R,  T[v  at  (reg  r  at  s)]  ^  S,  R,  T[v  at  r] 


[Tl-e] 


R(r)  =  (!,-) 


R(r)  =  (!,-) 


S,  R,  T[let  X  =  n  in  e]  ^  S,  R,  T[e[t/a:]] 
R(s)  =  (!,-) 


S,  R,  T[{v  at  r)  A]  S,  R,  T[vi\ 

[L-e] 


[T2-e] 


S,  R,  T[ref  V  at  (reg  r  at  s)]  ^  S  tt)  {1  v},  R,  ^[loc  1  at  r] 


[Ml-e] 


R(r)  =  (!,-) 


[R3-e] 


S,  R  W  {r  1-^  {h,  i)},  r[inuse  (reg  r  at  s)  in  t] 

^  S,  RW  {r  {b,i  —  l)},r[t] 


[R6-e] 


S  tt)  {1  t},  R,  T[ !  (loc  1  at  r)] 

^  S  W  {1  1-^  w},  R,  Tin] 


[M2-e] 


Stt)  {1 


^(r)  -(!,-) _ 

—  },  R,  ^[(loc  1  at  r)  :  =  t] 

^  s  w  {1 w},  R,  r[t] 


[M3-e] 


S,  R,  (el,  R[fork  62],  el)  ^  S,  R,  (el,  R[unit],  el,  62) 


Figure  10:  Extended  small  region  language:  reduction  rules 


A  source  program  e  is  well-typed  iff  {Xsr};{sr  reg{Xsr)@'X.sr}  1“  e  :  t;  {Xsr}-  Figure  12  shows  the 
additional  rules  for  typing  the  intermediate  expressions.  The  type  environment  is  extended  to  map  locations 
to  types  (e.g.,  F(l)  =  r). 

A.l  Proof  of  Safety 

We  reformulate  the  proof  for  the  extended  system.  We  also  fill  some  of  the  details  omitted  from  the  proof 
in  Section  2.4. 

All  expressions  mentioned  in  the  rest  of  the  section  are  assumed  to  be  in  the  intermediate  language  unless 
specified  otherwise. 

Definition  2  A  state  (S',  R,  e)  is  well-typed  under  the  environment  A;  F  iff 

(1)  dom{T)  =  dom{R)  U  dom{S),  fvars{ran{T))  C  A,  and  A;F  h  ;  {Xsr}  for  each  Ci  G  {e}. 

For  each  subexpression  of  the  form  A*A— :*.ei  at  —  of  e,  ei  does  not  contain  a  subexpression  of  the 
form  inuse  —  in—. 

(3)  For  each  r  €  dom{R)  such  that  r  yf  xsr,  the  number  of  occurrences  of  subexpressions  of  the  form 
inuse  {reg  r  at  — )  in  —  of  e  is  equal  to  i  where  R(r)  =  (— ,  i). 
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r(x)  =  r  A;rhei:Ti;L  A;  F  IdJ  {x  i-^  n}  h  62  :  r2; -L 

A;  r  h  X  :  r;  L  A;  F  h  let  x  =  ei  in  62  :  T2;  L 


A;  r  h  62  :  reg(X)@Z;  L2  fvars^Ti)  U  fvars{Li)  C  A  \±l  {a}  A;  F  h  ei  :  (Va.ri  r2)®X;  L2  fvars{y)  C  A 

A  l+J  {g};  F  a  {x  1-^  n}  h  61  :  r2;  Li _ X,  Z  £  L2  A;  F  h  62  :  ri[7/a];  L2  Li[7/a]  U  {X}  C  L2 

A;  F  h  AaAx:ri.6i  at  62  :  (Va.n  r2)@X;  La  ^  :  raR/a];  La 


A;FI-e:r;L  A;  F  h  6  :  re5(X)@Y;  L  X,YeL 
A;  F  h  6  at  6  :  r@X;  L 


(Tl-e) 


A;  F  h  6  :  (ri,  ra, Ti,  ...)@X;  L  XGL 
A;  F  h  e.i  ;  Ti;  L 


(T2-e) 


A;  F  h  61  :  3a. n;  L  fvarsij-i)  C  A  tt)  {a} 

A;  F  h  6  :  r[7/a];  L  A  W  {a};  F  tfJ  {x  1-^  ri}  h  62  :  ra;  L  fvars{T2)  Q  A 

-  (rLl-ej  - 

A;  F  h  pack  6  as  3a. r  :  3a. r;  L  A;  F  h  open  x  =  61  as  ri  in  62  :  ra;  L 


(E2-e) 


A;Fh6:  reg(Y)@Z;L  Y,  Z  £  L  X/Y  A;  F  h  6  :  reg(X)@Y;  L  Y£L 

A;  F  h  newregion  at  6  ;  3X.reg(X)@Y;  L  A;  F  h  freeregion  6  :  reg(X)@Y;  L 


A;F  h  61  :  reff(X)@Y;L  A;  F  h  62  :  r;  L  U  {X}  Y£L 


A;  F  h  useregion  61  in  62  :  r;  L 


(R3-e) 


A;FI-6i:r;L  A;  F  h  62  :  reg(X)@Y;  L  X,  Y  £  L 


A;  F  h  ref  61  at  62  :  re/(r)@X;  L 

(r)@X;L  A;Fh62 
A;  F  h  61  :=  62  :  r;  L 


(Ml-e) 


A;F  h  6  :  re/(r)@X;L  X£L 


A;F  h  !6  :  r;L 

A;F  h  61  :  re/(r)@X;L  A;  F  h  62  :  r;  L  X£L  A;  F  h  6  :  r;  {Xsr} 

A:  F  h  61  :  =  p.o  :  r:  F  Ar  F  h  fork  6  :  im.it: 


(M2-e) 


(S-e) 


Figure  11:  Extended  small  region  language:  type  checking  rules 

(4)  If  R{r)  =  {b,i)  and  i  >  0  then  5=1. 

(5)  For  each  1  £  dom{S),  A;  F  h  S'(l)  :  F(l);  — . 

We  write  A;  F  h  {S,R,e)  to  mean  that  {S,R,e)  is  well  typed  under  A;F.  Also  for  convenience,  we  write 
A  h  F  to  mean  fvars{ran(T))  C  A.  Note  that  A;  F  h  (S',  R,  e)  implies  A  h  F. 

Lemma  2  //  A;  F  h  e  :  r;  —  and  A  h  F  then  A  h  r. 

Proof:  By  induction  on  the  type  checking  derivation.  □ 

Lemma  3  (Substitution)  //  A  l±)  {a};F  l±l  {x  1-^  ti}  h  e  :  r2;L,  A  h  F  and  A;F  h  u  :  ri[7/d];  — ,  then 
A;F  F  e[v/x]  :  T2[7/d];  L[7/d]. 

Proof:  By  induction  on  the  type  checking  derivation.  □ 

Lemma  4  (Replacement)  Suppose  A;  F  h  E[ei]  :  —;Li.  Let  A;F  h  ei  :  r;  L2  be  the  subderivation.  If 
A;  F  h  62  :  t;  L2,  then  A;  F  h  i3[e2]  :  — ;  Li. 

Proof:  By  induction  on  the  type  checking  derivation.  □ 

Lemma  5  //  Ai;  Fi  h  e;  r;  Li,  Ai  C  A2,  Fi  C  Fa,  and  Li  C  L2,  then  A2;  F2  F  e;  r;  L2. 

Proof:  Trivial.  □ 

Theorem  3  (Subject  Reduction)  //Ai;Fi  F  (Si,i?i,ei)  and  Si,i?i,ei  ^  S2,i?2,e2,  then  there  exists 
A2,F2  such  that  A2;F2  F  (S2,i?2,e2). 


(F2-e) 
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A;  r  h  62  :  reg(X)@Z;  L2  fvarsiri)  U  fvars{Li)  C  A  W  {a} 
A  ttJ  {a};  r  W  Ti}  h  61  :  r2;  I/i  X,  Z  G  L2 

A;  r  h  A»Ax:».6i  at  62  :  (Va.Ti  T2)@X;  L2 
A;  r  h  6  :  r[7/Q;];  L 


(F3-e) 


A;  r  h  61  :  (Va.ri  r2)@X;  L2  fvars{^)  C  A 
A;r  h  62  :  ti[7/q];L2  Li[7/q]  U  {X}  C  L2 

A;  r  h  6i[»]  62  :  r2[7/a];  L2 


(E3-e) 


A;  r  h  61  :  3a. ri;  L  fvars{T\)  C  A  W  {a} 

A  W  {a};  r  W  {x  1-^  n}  h  62  ’■  T2',L  fvars{T2)  C  A 


A;  r  h  pack  6  as  •  :  3a. r;  L 

r(r)  =  X  r(s)=Y  A;r  h  6  ;  r;L  U  {X}  YGL 
A;  r  h  inuse  (reg  r  at  s)  in  6  ;  t;  L 


A;  r  h  open  x  =  61  as  •  in  62  :  T2;  L 


(E4-e) 


(R4-e) 


A;  r  h  abort  :  r;  L 


(A-e) 


A;  r  h  unit  :  unit,  L 


fvars{T\)  U  fvars{Li)  C  A  W  {a} 

A  W  {a};  r  W  {a;  n}  h  6  :  T2;  I/i  r(r)  =  X 

A;  r  h  A»Ax:».6  at  r  :  (Va.ri  r2)®X;Z/2 


(FV-e) 


A;rhiT:-f;L  r(r)  =  X 
A;  r  h  -y  at  r  :  r@X;  L 


(TV-e) 


FT— -  (RV-e) 

A;  r  h  reg  r  at  s  :  reg(X)@Y;  L 


r(l)  =  r _ r(r)  =  X 

A;  r  h  loc  1  at  r  :  ref  L 


(MV-e) 


Figure  12:  Extended  small  region  language:  additional  type  rules  for  intermediate  expressions 


Proof:  The  conditions  (2),  (3),  and  (4)  can  be  proved  independent  of  the  choice  of  A2,r2.  The  condition 
(2)  follows  from  inspection  of  the  reduction  rules.  Given  (2),  (3)  is  straightforward  by  inspection  of  [R4-e] 
and  [R6-e] .  The  condition  (4)  is  straightforward  by  inspection  of  [R4-e] . 

It  remains  to  find  A2  and  r2  to  satisfy  (1)  and  (5).  We  do  this  via  case  analysis  on  the  reduction  rules. 

[Fl-e]  Let  A2  =  Ai  and  r2  =  Fi.  Let 

if[A*Ax:*.e  at  (reg  r  at  s)]  G  {el} 

be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

A2;  F2  F  reg  r  at  s  :  reg{X)@Z',  L2 
fvars{Ti)  U/?;ars(Li)  C  A2  ttl  {o;} 

A2  l±l  {a};  F2  l±)  (a;  ri}  F  e  :  r2;  Li  X,  Z  G  L2 

A2;  F2  F  A*Ax:*.e  at  (reg  r  at  s)  :  (Va.ri  T2)@X;  L2 
By  inspection  of  (RV-e),  it  must  be  the  case  that  F2(r)  =  X.  Hence  by  (FV-e), 

A2;  F2  F  A*Ax:*.e  at  r  :  (Va.ri  r2)@X;  L2 


By  Lemma  4,  it  follows  that 

A2;  F2  F  if[A*Ax:*.e  at  r]  :  — ;  {Xsr} 

Hence  (1)  holds.  (5)  is  trivial. 

[F2-e]  Let  A2  =  Ai  and  F2  =  F2.  Let 

if[(A*Ax:*.e  at  r)[*]  r]  G  {el} 


(F4-e) 


(U-e) 
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be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 


^2;  r2  b  (A*Ax:*.e  at  r)  :  (Va.Ti  r2)@X;  L2 

A2;T2  b  V  :  Ti[7/d];L2 

Li[j/d]  U  {X}  C  L2 _ fvars{^)  C  A2 

A2; r2  b  (A*Ax:*.e  at  r)[*]  v  :  T2[j/d\-,L2 

By  inspection  of  (FV-e),  it  must  be  the  case  that 

A2  l±l  {d};  r2  l±l  {a;  ti}  b  e  :  T2;  Li 

Hence  by  Lemma  3,  it  follows  that 

A2;r2  b  e[v/x]  :  r2[7/d];  Li[7/d] 


By  Lemma  5, 

By  Lemma  4,  it  follows  that 
Hence  (1)  holds.  (5)  is  trivial. 


A2;r2  b  e\vlx\  :  r2[7/d];L2 
A2;r2  b  E[e[v/x\]  :  {Xsr} 


[E-e]  Let  A2  =  Ai  and  r2  =  Fi.  Let 

if  [open  X  =  (pack  v  as  •)  as  •  in  e]  S  {el} 

be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

A2;  F2  b  pack  V  as  •  :  3a. ti;  L  fvars(Ti)  C  A2  W  {a} 

A2  W  {a};F2  l±)  (x  1-^  Ti}  b  e  :  r2;  L  fvars{T2)  C  A2 
A2;  F2  b  open  X  =  (pack  z;  as  •)  as  •  in  e  :  r2;  L 

By  inspection  of  (E3-e),  it  must  be  the  case  that  A2;  F2  b  v  :  T[7/a];  L.  Hence  by  Lemma  3,  it  follows  that 

A2;F2  be[z;/a;]  :  T2[7/d];  ^[7/0] 

We  have  T2[7/d]  =  T2.  Since  the  subderivation  appears  in  the  derivation  having  {Xsr}  as  its  effect  set,  it  is 
easy  to  see  that  fvars{L)  C  A2.  So  L[^/d]  =  L.  Hence  we  have 

A2;F2  b  e\vlx\  :  T2\L 


By  Lemma  4,  it  follows  that 


Hence  (1)  holds.  (5)  is  trivial. 


A2;F2  b  E[e[v/x\]  :  (Xs^j 


[Rl-e]  Let  W  ^  Ai.  Let  A2  =  Ai  l±)  {W}  and  F2  =  Fi  l±l  (t  i-z  w}.  It  is  easy  to  see  that  dom{T2)  = 
dom{R  l±l  {t  I— !■  (1, 0)1)  U  dom{S)  and  fvars{ran{T2))  C  A2. 

For  each  thread  e  €  {el},  A2;  F2  be:—;  {Xgr}  by  Lemma  5. 

Let 

if[newregion  at  (reg  r  at  s)]  G  {el} 

be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

A2;  F2  b  reg  r  at  s  :  reg{Y)@Z;  L  Y,  ZGL  Xy^Y 
A2;  F2  b  newregion  at  (reg  r  at  s)  :  3X.reg(X)@Y;  L 
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By  inspection  of  (RV-e),  it  must  be  the  case  that  r2(r)  =  Y.  Hence  by  (RV-e)  again  A2,r2  h  reg  t  at  r  : 
reg(W)@Y.  By  (E3-e), 

A2;  r2  b  pack  (reg  t  at  r)  as  •  :  3X.reg(X)@Y;  L 

By  Lemma  4,  it  follows  that 

A2;  r2  b  if[pack  (reg  t  at  r)  as  •]  :  — ;  {Xsr} 

Hence  (1)  holds.  (5)  is  trivial. 

[R2-e]  Let  A2  =  Ai  and  r2  =  Li.  Let 

if [freeregion  (reg  r  at  s)]  G  {el} 

be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

A2;  r2  b  reg  r  at  s  :  reg(X)@Y;  L  Y  £  L 
A2;  r2  b  f  reeregion  (reg  r  at  s)  :  reg{X)@Y;  L 

Hence  A2;  r2  b  reg  r  at  s  :  reg(X)@Y;  L.  By  Lemma  4,  it  follows  that 

A2;  r2  b  E[reg  r  at  s]  :  (Xsrj 

Hence  (1)  holds.  (5)  is  trivial. 

[R3-e]  Let  A2  =  Ai  and  r2  =  Li.  By  (A-e), 

A2;  r2  b  abort  :  {Xsr} 

Hence  (1)  holds.  (5)  is  trivial. 

[R4-e]  Let  A2  =  Ai  and  r2  =  Li.  Let 

if[useregion  (reg  r  at  s)  in  e]  G  {el} 

be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

A2;  r2  b  reg  r  at  s  :  reo(X)@Y;  L 

A2;T2  b  e  :  t;LU  {X} _ Y  £  L 

A2;  r2  b  useregion (reg  r  at  s)  in  e  :  r;  L 

By  inspection  of  (RV-e),  it  must  be  the  case  that  r2(r)  =  X  and  r2(s)  =  Y.  Hence  by  (R4-e), 

A2;  r2  b  inuse  (reg  r  at  s)  in  e  :  t;  L 

By  Lemma  4,  it  follows  that 

A2;  r2  b  if  [inuse  (reg  r  at  s)  in  e]  :  — ;  {Xgr} 

Hence  (1)  holds.  (5)  is  trivial. 

[R5-e]  Similar  to  the  case  [R3-e]. 
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[R6-e]  Let  A2  =  Ai  and  r2  =  Li.  Let 

i?[inuse  (reg  r  at  s)  in  u]  S  {el} 

be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

r2(r)  =  X  r2(s)  =  Y  A2;r2ht.:r;£U{X}  YeL 
A2;  r2  b  inuse  (reg  r  at  s)  in  u  :  t;  L 

Since  v  is  a  value,  by  inspection  of  the  type  checking  rules,  A2;  T2  v  :  t;  L.  By  Lemma  4,  it  follows  that 

A2;T2hE[v]  :  (X^rj 

Hence  (1)  holds.  (5)  is  trivial. 

[Tl-e]  Similar  to  the  case  [Fl-e]. 

[T2-e]  Similar  to  the  case  [F2-e]. 

[L-e]  Similar  to  the  case  [F2-e]. 

[Ml-e]  Let  if[ref  v  at  reg  r  at  s]  S  {el}  be  the  active  thread.  Then  by  inspection  of  the  type  checking 
rules,  there  is  a  subderivation 

Ai;Fi  h  u  :  r;L 

Ai;  Fi  h  reg  r  at  s  :  reg(X)@Y;  L  X,  YGL 
Ai;  Fi  h  ref  v  at  reg  r  at  s  :  re/(T)@X;  L 

Let  A2  =  Ai  and  F2  =  Fi  l±)  {1  1— >  r}.  By  Lemma  2,  dom{T2)  =  dom{R)  U  dom{S  l±l  {1  v})  and 

fvars{ran{T 2))  C  A2. 

For  each  thread  e  S  {el},  A2;F2  F  e  :  — ;{Xsr}  by  Lemma  5.  By  inspection  of  (RV-e),  it  must  be  the 
case  that  F2(r)  =  X.  Hence  by  (MV-e), 

A2;  F2  F  loc  1  at  r  :  re/(r)@X;  L 

By  Lemma  4,  it  follows  that 

A2;  F2  F  if[loc  1  at  r]  :  {Xgr} 

Hence  (1)  holds.  Since  A2;F2  F  u  :  r;  L,  (5)  holds. 

[M2-e]  Let  A2  =  Ai  and  F2  =  F2.  Let  E\\  (loc  1  at  r)]  €  {el}  be  the  active  thread.  Then  by  inspection 
of  the  type  checking  rules,  there  is  a  subderivation 

A2;  F2  F  loc  1  at  r  :  re/(T)@X;  L  X  G  L 
A2;  F2  F  !  (loc  1  at  r)  :  r;  L 

By  inspection  of  (MV-e),  it  must  be  the  case  that  F2(l)  =  r.  Hence  by  (5)  (on  the  left  state),  A2;  F2  F  u  :  r;  L. 
By  Lemma  4,  it  follows  that 

A2;T2^E[v]  :  {X^r} 

Hence  (1)  holds.  (5)  is  trivial. 
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[M3-e]  Let  A2  =  Ai  and  r2  =  r2.  Let 

£^[(loc  1  at  r)  :  =  w]  G  {e!} 

be  the  active  thread.  Then  by  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

A2;  r2  h  loc  1  at  r  :  re/(r)@X;  L 

A2;r2  h  t  :  t;L _ X  €  L 

A2;  r2  b  (loc  1  at  r)  :  =  v:t;L 

By  Lemma  4,  it  follows  that 

A2;T2^E[v]  :  {X^r} 

Hence  (1)  holds. 

By  inspection  of  (MV-e),  it  must  be  the  case  that  r2(l)  =  r.  Hence  (5)  holds. 

[S-e]  Let  A2  =  Ai  and  r2  =  r2.  There  is  a  subderivation  for  the  thread  if  [fork  62] 

A2;r2  b  62  :  r;  {Xsr} 

A2;r2  b  fork  62  :  unit]  L 

By  (U-e),  A2;  r2  b  unit  :  unit;  L.  By  Lemma  4,  it  follows  that 

A2;  r2  b  S[unit]  :  {Xsr} 

We  also  have  A2;  r2  b  62  :  — ;  {Xgr}.  Hence  (1)  holds.  (5)  is  trivial.  □ 

Lemma  6  //A;r  b  E[e]  :  — ;  {Xgr}  then  there  is  a  sub- derivation  A;  L  b  e  :  — ;  L  such  that  if  X  G  L  and 
X  yf  Xsr  then  there  is  an  occurrence  of  inuse  (reg  r  at  — )  in  —  in  E[e]  such  that  r(r)  =  X. 

Proof:  By  inspection  on  the  definition  of  evaluation  contexts  and  the  corresponding  type  checking  rules.  □ 

Theorem  4  (Progress)  //  A;  L  b  (S',  R,  e)  and  not  all  of  e  is  a  value,  then  there  is  a  reduction  from 
{S,R,e). 

Proof:  The  main  part  of  the  proof  is  in  showing  that  condition  of  the  form  i?(.  ..)  =  ...  in  the  hypotheses 
of  each  reduction  rule  is  satisfied.  These  hypotheses  appears  across  multiple  reduction  rules,  but  essentially 
the  same  argument  can  be  used  for  all  of  them.  We  shall  show  this  for  the  case  e  contains  if[A*Ax  : 
•  .e  at  (reg  r  at  s)]. 

By  inspection  of  the  type  checking  rules,  there  is  a  subderivation 

A;  r  b  reg  r  at  s  :  reg(X)@Z;  L2 
fvars{Ti)  U  fvars{Li)  C  A  l±)  {a} 

A  l±l  {a};  r  l±l  {x  I— >  Ti}  b  e  :  T2;  Li  X,  Z  G  L2 

A;  r  b  A*Ax:*.e  at  (reg  r  at  s)  :  (Va.Ti  r2)@X;  L2 

By  Lemma  6,  there  is  an  occurrence  of  inuse  (reg  r  at  — )  in  —  such  that  r(r)  =  X  and  an  occurrence  of 
inuse  (reg  s  at  — )  in  —  such  that  r(s)  =  Z.  By  Definition  2  (3)  and  (4),  this  implies  that  i?(r)  =  (Ij— ) 
and  R{s)  —  (1,—).  Hence  [Fl-e]  can  be  applied  to  reduce  the  state. 

Other  cases  can  be  proved  analogously.  □ 

Theorem  5  Let  ei  be  a  well-typed  program  in  the  source  language.  Let  62  be  its  corresponding  type-erased 
program  in  the  intermediate  language.  Then  {Xsr};  {rsr  ^  Xsr}(0,  (rsT-  1— >  (1,1)},  02)  where  rsr  is  the 
starting  region. 

Proof:  Trivial.  □ 

Corollary  1  (Type  Soundness)  Lf  a  source  program  e  is  well  typed  then  it  does  not  get  stuck,  that  is,  e 
is  memory  safe. 

Proof:  By  Theorem  3,  Theorem  4  and  Theorem  5  □ 
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